LE BURN DOWN

Le Burn Down Chart permet de suivre la progression d’une équipe sur son objectif de sprint en mesurant le travail effectué et le travail restant avec le temps disponible.
Cependant, au-delà d’un outil de suivi, le Burn Down permet aussi de détecter des dysfonctionnements au sein d’une équipe ou même au sein d’une organisation.

Nous allons voir au travers de cet article comment le Burn Down Chart permet d’identifier des problèmes de différentes typologies :

• Systémique (file d’attente en dehors de la sphère d’influence d’une équipe par exemple)
• Organisationnel
• D’équipe (dans la maîtrise de SCRUM)

Ci-dessus vous pouvez visualiser le Burn Down idéal, connu de tous. Nous allons dans la suite de cet article visualiser quatre différents patterns de Burn Down révélant des dysfonctionnements d’équipe ou d’organisation. Pour l’heure nous allons uniquement nous intéresser au premier bad pattern Scrum : la validation des US (User Story) tardive ou non-dépendante de l’équipe.

UNE VALIDATION TARDIVE OU HORS-EQUIPE

Avant de lire la suite de cet article, il est à noter que le Burn Down Chart est construit et reflète l’avancement de l’équipe en cohérence avec la définition du terminé (définition of done) déterminée par celle-ci.

Ce bad pattern peut être exprimé de la façon suivante : la validation des US est soit faite trop tardivement par le product owner qui les accepte ou les rejette au dernier moment dans le sprint soit, encore pire, la validation des US ne dépend pas de l’équipe, mais d’une entité extérieure.

Comme vu ensemble, ce burn down met en lumière différents problèmes. Essayons d’identifier leurs sources :

Le manque de disponibilité du product owner : le Product Owner n’est pas disponible pour l’équipe. Il n’est pas présent pour clarifier, donner du sens et valider les développements effectués.

Ce manque de disponibilité crée un goulot d’étranglement sur les tests et tire donc indirectement à la baisse la vélocité de l’équipe et ainsi la valeur apportée au produit.

La fluidité de communication : nous rencontrons souvent ce problème avec un Proxy Product Owner qui, par définition, travaille à distance de l’équipe. Dans ce genre de cas, il faut penser à affiner sa définition du terminé.

Les conséquences

Comme vu ci-dessus, il y a de lourds impacts. Entre autres, la baisse de la vélocité, la mise en péril de l’incrément produit, la perte de la notion d’engagement, car cet engagement ne dépend pas directement de l’équipe, les débordements et le reliquat à traiter (ou pas suivant la re-priorisation du Product Owner) sur le prochain sprint ce qui induit un surplus de complexité.

Ainsi, si ce n’est pas un épiphénomène, c’est-à-dire d’identifier et de traiter les causes du problème.

Que faire dans ce cas ?

Plusieurs pistes sont possibles et à envisager pour rectifier ces problèmes d’équipes :

• L’enrichissement du burn-down : Créer par exemple deux courbes :
  • Suivre comme dans l’actuel le « Done = développé + testé »
  • Suivre le « développé » uniquement
  • Ceci aura pour effet de visualiser le goulot d’étranglement et de préserver la notion d’engagement de l’équipe
• Repenser la stratégie de tests si le PO n’est pas disponible
• etc.

UNE PROGRESSION LENTE OU UN SUR-ENGAGEMENT

Plusieurs comportements peuvent être à l’origine de ce genre de Burn Down :

L’équipe trop ambitieuse : l’objectif du sprint est trop ambitieux et l’équipe réalise seulement pendant le sprint qu’elle n’atteindra pas l’objectif du sprint. (A noter : s’il est acceptable de viser haut et d’échouer, il ne faut pas que cela devienne une habitude ou un modèle régulier, car cela influence négativement la confiance de l’organisation dans l’équipe.)

L’équipe soumise : l’équipe n’est pas assez responsabilisée et n’ose pas affronter le Product Owner en donnant une vision réaliste mais peut être perçue comme douloureuse de sa capacité de production sur un sprint. Cette fausse promesse peut aussi mener à un manque de confiance de l’organisation vers l’équipe.

La variance de l’équipe : les équipiers tombent malade ou partent, partent en vacances sans que cela n’ait été identifié lors de lancement du sprint.

Le changement de priorité de dernière minute : l’équipe doit résoudre un problème critique – souvent un bug – qui laisse moins de capacité à accomplir l’objectif de sprint. Selon la fréquence de ces perturbations, il faut peut-être laisser du mou sur l’engagement de l’équipe.

Les adhérences et dépendances : l’équipe fait face à des dépendances en dehors de sa sphère d’influence non-prévisibles lors de la planification du sprint. (Note : Un dysfonctionnement systémique classique.)

L’AUGMENTATION DU PERIMETRE

La plupart du temps, on observe ce Burn Down lorsque la préparation du sprint n’a pas été bien menée.

Un mauvais découpage : l’équipe n’est pas parvenue à découper les stories et n’a donc pas identifié que l’effort de création d’un incrément de produit (du sprint) allait être plus important que prévu. Si cela se produit régulièrement, cela signifie que l’équipe a accepté des user stories non comprises ou avec trop d’incertitudes, ce qui montre de sérieux dysfonctionnements.

D’importantes variations sur le périmètre : souvent dues à un manque de priorisation ou à un manque de mou ne permettant pas de gérer les urgences.

Que faire dans ce cas ?

Quelques idées
Instaurer une séance de backlog refinement à mi-sprint afin d’arriver en lancement de sprint avec des user stories mâtures.
Se laisser un peu de mou sur le sprint (ne pas s’engager aux limites de sa capacité de production) à combler avec des actions d’améliorations au besoin afin d’avoir de la bande passante pour gérer les urgences.

Le sous-engagement

Attention, ce Burn Down n’est un anti-pattern SCRUM que si celui-ci se produit régulièrement. On ne va pas critiquer une équipe qui travaille parfois mieux que prévu !

Néanmoins, si ce Burn Down est une habitude dans vos équipes :

L’équipe trop prudente : l’équipe a probablement surestimé l’effort lors de son estimation. Cette mauvaise estimation peut découler d’une user story non maîtrisée, ou d’une angoisse de l’équipe dans un contexte trop strict ou l’on n’accepte pas « l’échec ».

Pas de visibilité sur les actions techniques : l’équipe garde de la capacité de production pour traiter des tâches techniques (refacto / gestion de la dette technique) sans donner de la visibilité sur ces actions.

EN CONCLUSION

1. C’est une bonne idée d’analyser parfois le Burn Down, pourquoi pas après un stand-up ou lors d’une rétrospective en essayant d’identifier les problèmes systémiques.
2. On peut donner encore plus de transparence et de visibilité en couplant le Burn Down Chart avec d’autres indicateurs, par exemple le cycle time, le lead time, etc.
3. Il est bénéfique de mettre à jour le Burn Down lors des mêlées quotidiennes sans que cela soit systématiquement au Scrum Master de le faire. N’hésitez pas à créer une tâche tournante au sein de l’équipe !

Par Robin, Consultant digital, à Paris