Série “les indicateurs d’équipe” : Le Cumulative Flow Diagram

Published in

Just-Tech-IT

9 min readJun 8, 2022

Nous présentons dans cet article le Cumulative Flow Diagram (ou Diagramme de flux cumulés), un indicateur essentiel pour:

Suivre votre projet,
Mesurer la performance de l’équipe,
Anticiper des risques,
L’amélioration continue de l’équipe.

Comme vous le constaterez, nous y avons ajouté quelques exemples pour l’illustrer.

Le Cumulative Flow Diagram (CFD), qu’est-ce que c’est ?

Le Cumulative Flow Diagram est utilisé pour piloter vos Releases.

Il présente l’avancement appelé le « réalisé » à savoir le travail accompli par rapport à l’objectif. Son intérêt réside également dans la mesure de la prédictibilité. Il permet de visualiser l’atterrissage en fonction des variations de périmètre, de l’avancement et des projections.

Il est constitué de 2 axes :

Sur l’axe des abscisses : le temps,
Sur l’axe des ordonnées : le nombre de stories (à savoir : les Userstories, Technical Stories et les Bugs).

Nous avons recensé 4 étapes essentielles pour cet indicateur :

La Backlog,
Rédaction terminée : ce qui est prêt à être développé,
Développement terminé : ce qui est prêt à être testé,
Test terminé : ce qui est prêt à être livré.

C’est un indicateur propre à la Squad, Il ne pourra donc pas être comparé à d’autres équipes car leur contexte, leurs maturité et leurs expériences sont différents.

Prenons l’exemple d’une équipe (ou squad) qui consulte son Cumulative Flow Diagram en semaine 5.

Un outil de communication

Comme tout graphique, l’objectif est la communication. Le Cumulative Flow Diagram permet de partager les informations d’avancement et de variation de périmètre au sein de l’équipe mais aussi et surtout en dehors de l’équipe (Métier, contributeurs, Tribu …).

C’est un outil factuel qui permet à l’équipe de :

Echanger, expliquer,
Remonter des risques,
Mettre en place des actions pour lever les risques,
Prendre des décisions.

Quand consulter cet indicateur ?

Le conseil est de présenter cet indicateur à l’équipe une fois par semaine, lors du daily du lundi par exemple. Pour que l’équipe puisse suivre la Release et réagisse au plus tôt en cas de risques, il est important d’avoir une fréquence régulière et rapprochée.

Le Scrum Master ou tout autre membre de la squad affichera le Cumulative Flow Diagram et demandera à l’équipe d’interpréter les courbes. Une fois cette interprétation faite avec des explications associées, il sera nécessaire de trouver des actions pour résoudre les risques rencontrés et désigner un responsable de ce suivi.

Il est tout à fait possible d’ajouter cette action dans le kanban de la squad pour en suivre l’avancée et sa résolution. Il en sera de même pour les risques remontés que l’on pourra ajouter dans le kanban des risques de notre équipe.

Mais, attention, il y a des contraintes

Il est indispensable de responsabiliser chaque membre de l’équipe sur la mise à jour les stories dans votre outil Kanban (exemple: Jira). Leur statut doit être au plus près de la réalité pour avoir des indicateurs utilisables et fiables.

Pour interpréter de bons indicateurs, le kanban doit être à jour.

Quelques exemples

Tout d’abord, une mise en situation :

La Squad “John Doo” a décidé de se réunir chaque lundi matin pour présenter son Cumulative Flow de la version en cours. L’équipe est dans sa 7ème semaine de Release. Pour information, elle a décidé de ne pas convier le Métier, ni le Product Manager du domaine à cette réunion.

Nous voici en début de réunion.

Cas d’un kanban dont le statut des stories n’a pas été mis à jour

Marc (Le Scrum Master) — “Bonjour, je vous présente le Cumulative Flow Diagram que je viens de créer dans EazyBI.”

Puis, il décrit l’indicateur avec ses axes et les valeurs remontées.

Marc — “Que pouvez-vous me dire sur ces courbes ?”

L’équipe remarque un problème sur les courbes “Développement terminé” et “Test terminé” car cela ne reflète pas la réalité.

Jean (le Techlead) — “Les indicateurs sont faux car nous avons bien avancé sur nos développements et nos tests. Il doit y avoir un soucis au niveau de l’indicateur.”

En regardant le Kanban dans JIRA, l’équipe a finalement constaté qu’il ne s’agissait pas d’un problème d’indicateur. En fait, les stories avaient toutes été déplacées à la fin de la semaine 6. L’équipe a décidé de mettre à jour les stories régulièrement dans JIRA.

Dans cet exemple, l’indicateur n’était pas exploitable. Sans discussion d’équipe, nous aurions pu imaginer que l’équipe de développement n’avait pas développé pendant 6 semaines, alors que ce n’était pas le cas.

Cas d’un kanban avec une courbe plate pour les développements

Frédéric (Le Product Owner) — “Bonjour, je vous présente le Cumulative Flow Diagram de cette semaine. Je crois qu’il y a un soucis au niveau du développement. Qu’en pensez-vous ? “

Jean (le Techlead) — “Oui, c’est ce que nous disions en daily. Nous avons rencontré un soucis technique la semaine dernière qui a fait que nos développements ont été bloqués. Nous avons enfin trouvé une solution que l’on va mettre en place cette semaine.”

Abdallahi (Le TestLead) — “Comme on le voit sur la courbe, nous avons fini nos tests et nous attendons vos futurs développements. Que peut-on faire en attendant ?”

Pendant la réunion, l’équipe a décidé de :

Mettre à jour le statut du risque de retard de livraison de la MMF suite à problème technique (risque qui avait été remonté lors d’un daily), en indiquant que la solution avait été trouvée,
De proposer au métier de déprioriser une story dont l’effort était important dans la Release pour permettre de finaliser la fonctionnalité (MMF) impactée par le problème technique,
De demander aux testeurs d’analyser les bugs remontés en semaine 6, en attendant les prochains développements.

Dans cet exemple, l’indicateur a permis à l’équipe de faire le point sur le problème technique, trouver des solutions pour mener à bien la MMF en cours et trouver des activités pour les testeurs.

Cas d’un kanban avec une chute du nombre de stories

Marc (Le Scrum Master) — “Bonjour, je vous présente le Cumulative Flow Diagram de cette semaine. Nous avons une chute du nombre de stories la semaine dernière.”

Frédéric (Le Product Owner) — “Oui, vous vous souvenez, c’est le métier qui a dépriorisé une fonctionnalité (MMF) alors que nous étions en plein développement. C’est pour cela que l’on a déplacé les userstories dans la Release suivante.”

L’équipe a remonté au Product manager le fait que ce qui a été développé risque d’être perdu pour la prochaine Release en cas de changement de besoin. Dans le cas contraire, il sera nécessaire de prendre du temps pour reprendre le code, en sachant aussi qu’il est possible que ce soit un autre développeur qui reprenne le sujet. Il y aura donc un impact sur la prochaine Release.

Le Product Owner a décidé d’être plus vigilant quant aux priorisations, en challengeant plus le Métier pour éviter d’avoir de nouveau ce type de situation.

Dans cet exemple, l’indicateur montre une chute du nombre de stories qui est expliquée comme le fait d’une dépriorisation soudaine par le Métier d’une fonctionnalité.

Cas d’un kanban avec un goût de Cycle en V

Marc (Le Scrum Master) - “Bonjour, je vous présente le Cumulative Flow Diagram de cette semaine. Comme vous pouvez le voir les Userstories ont bien été terminées en semaine 3, ce qui a permis de démarrer les développements. Nous avons pris quand même du retard et il nous reste pas mal de tests à faire alors qu’il ne nous reste plus qu’une semaine avant la mise en Production.”

Jean (le Techlead) — “Il faudrait peut-être aider les équipes de tests ?”

Frédéric (Le Product Owner) — “Je n’ai pas encore terminé d’écrire les userstories pour la prochaine Release. Tu as raison, il faudrait que l’on aide les équipes de tests pour une partie de l’équipe et pour l’autre de faire de la dette technique en attendant.”

Cet exemple présente une équipe qui a décidé de faire du cycle en V (ou appelé aussi modèle Waterfall), à savoir qu’une étape doit attendre la fin de la précédente pour démarrer.

Cas d’un kanban avec un Product Owner malade

Iman (développeuse) — “Bonjour, je vous présente le Cumulative Flow Diagram de cette semaine. Comme vous le savez notre Product Owner est malade depuis une semaine et son arrêt maladie est prolongé d’une semaine. On a encore des userstories dans la Backlog. En plus, elles font partie de la même fonctionnalité (MMF). Vous vous souvenez, le Métier nous a dit, pendant le Release Planning, qu’elle était essentielle pour eux.”

Jean (le Techlead) — “Oui, en plus l’équipe de Dev n’est plus alimenté cette semaine.”

Abdallahi (Le TestLead) — “Pareil pour l’équipe de test.”

L’équipe a remonté l’alerte au Métier et au Product Manager, en indiquant un risque de dépriorisation de la fonctionnalité, n’ayant pas de Business Analyst pour faire avancer le sujet. Le Product Manager a décidé de travailler sur les Userstories car il avait suivi les ateliers avec le Métier et le Product Owner.

Elle a aussi décidé de travailler sur des technical stories pour réduire la dette technique, en attendant d’être alimentée en userstories.

Sans l’interprétation de l’équipe de cette courbe, nous aurions pu penser qu’elle était en avance sur le planning, alors qu’une fonctionnalité essentielle pour le Métier était sur le point de ne pas être développée.

Cas d’un kanban avec un retard d’objectif

Marc (Le Scrum Master) - “Bonjour, je vous présente le Cumulative Flow Diagram de cette semaine. Nous constatons qu’il nous reste 2 semaines avant la mise en Production (la courbe rouge verticale). les courbes en pointillés nous montrent que nous n’atteindrons pas l’objectif.”

Jean (le Techlead) — “De ce que je vois, les stories qui nous restent ont des points d’effort très élevées. On ne va pas pouvoir les développer rapidement.”

L’équipe a décidé de contacter le Métier pour l’informer du retard d’objectif et trouver avec eux une solution (dépriorisation …). Le Product Manager sera aussi mis au courant.

Lors de la prochaine Retro, l’équipe a décidé de faire un bilan de ce qui s’est passé et de trouver des solutions (périmètre fonctionnel trop ambitieux ? Challenger plus le Métier ? Prévision de capacité/vélocité de l’équipe trop optimiste ? …).

Les courbes prévisionnelles, ainsi que la mise en place d’une date limite permettent de se projeter sur les prochaines semaines et d’anticiper des risques.

Cas d’un kanban avec un nouveau besoin métier en pleine Release

Iman (développeuse) — “Bonjour, je vous présente le Cumulative Flow Diagram de cette semaine. Je viens de découvrir un pic au niveau de la Backlog. C’est normal ? Alors que l’on est sur le point de terminer la Release.”

Frédéric (Le Product Owner) — “On vient d’avoir un besoin urgent à traiter qui vient du Métier. Vous pensez que nous pourrions le traiter ?”

L’équipe a demandé au Product Owner de leur expliquer le sujet et s’il avait challengé le Métier quant à la valeur business du besoin et de son urgence. Elle va proposer au Métier de prendre en compte en priorité ce sujet pour la prochaine Release.

Si cela se produit fréquemment, l’équipe a décidé de se donner une marge de capacité/vélocité afin d’absorber toute nouvelle demande lors de futures Releases.