Pratique de l'application du Cumulative Flow dans le contexte de Scrum et SAFe

Dans cet article, je prévois de raconter comment, dans notre pratique, nous appliquons le Cumulative Flow Chart dans Scrum dans le processus de travail selon le framework SAFe

Je commencerai, peut-être, par un lien vers cet article - ici, à mon avis, sa destination sous forme standard est bien décrite, je recommande de l'étudier avant de lire mon article. Ci-dessous, je décrirai comment nous l'avons adapté pour le processus Scrum (à l'origine il est utilisé dans Kanban) et quels problèmes il nous aide à résoudre lors du travail par sprints.

Précédemment, dans l'article sur les Burn Down Charts j'ai déjà dit que là nous voyons l'apparition d'un nouveau travail et la combustion de l'ancien. Le problème du Burn Down Chart est que, contrairement au Cumulative Flow Chart, on n'y voit pas le mouvement des User Stories par statuts. Quand nous commençons à observer les mouvements par statuts dans le Cumulative Flow Chart, nous commençons à voir les changements quotidiens (le Burn Down Chart peut ne pas changer pendant plusieurs jours et dans certains contextes cela peut être tout à fait normal) et nous pouvons remarquer des problèmes plus subtils.

Voici à quoi cela peut ressembler en dynamique (sur l'image, un diagramme construit sur des données réelles).

Dans cet exemple, nous voyons ce qui suit

• Les 7 premiers jours du sprint, très peu de travail se trouve en test et cela ne change pas
• Du DOR (ici c'est un brouillon) vers le travail, les User Stories partent de manière assez uniforme - c'est bien.
• Comme sur le Burn Down, nous voyons que selon la tendance les User Stories ne seront pas terminées à la fin du sprint

Ces 3 observations combinées conduisent à la conclusion suivante. Ici, clairement, encore aux premiers stades (quelque part au deuxième-troisième jour du sprint), le Scrum Master aurait dû attirer l'attention sur la couche "Test", qui est trop petite et ne change pas assez longtemps (vérifier quelle en est la cause). On peut supposer que le volume de travail prêt pour le test ne peut pas être testé pour certaines circonstances, mais alors cela signifie que les testeurs sont inactifs, et donc, au minimum, il vaut la peine de les écouter plus attentivement au prochain standup.

Si l'on parle de la pratique d'application, par exemple, je publie quotidiennement dans le chat de l'équipe toutes les métriques avant le standup en mentionnant toute l'équipe.

En général, il ne faut pas oublier que les métriques doivent tout de même être correctement interprétées. Savoir voir réellement les problèmes systémiques s'ils existent et ne pas percevoir comme des problèmes ce qui, dans votre contexte, peut même être un signe positif