Comment calculer les valeurs dans le Burn Down Chart en Scrum

Après la publication auprès d'amis du premier article sur le Burn Down Chart, dans les commentaires, la deuxième question qui a été posée était : « On ne comprend pas comment toutes ces valeurs sont calculées ». C'est pourquoi, dans cet article, je vais essayer d'expliquer comment nous calculons les valeurs quotidiennes sur le Burn Down Chart. Comme d'habitude, je serai ravi de tous les commentaires de mes collègues si jamais je dis quelque chose de travers, mais je veux tout de même croire que le sujet est suffisamment clair pour moi.

Rappelons encore une fois à quoi ressemble ce diagramme.

Dans cet exemple, un sprint de 10 jours est considéré. On y voit que 2 jours se sont écoulés (puisque seuls les 2 premiers segments sont colorés par le graphique vert).

Nous voyons aussi le volume total du sprint - c'est la ligne pointillée qui montre que le volume total du sprint lundi à 10h00, mardi à 10h00 et mercredi à 10h00 n'a pas changé et est égal à 17 SP (Story Points).

Selon la méthodologie Scrum, le volume total de travail au sein du sprint ne change pas pendant le sprint, c'est pourquoi cette ligne est souvent tracée d'emblée pour tout le sprint (les 10 jours). Elle aide aussi à évaluer ce qu'il reste à faire de manière plus visuelle que si elle se terminait au troisième jour dans la variante actuelle.

Le brûlage réel (graphique vert) montre le travail effectivement restant. C'est-à-dire qu'actuellement l'équipe a réalisé 1 Story Point sur les 17 qui doivent être réalisés pour terminer le sprint avec succès. Est considérée comme réalisée le plus souvent une tâche au statut « Done » (ce que signifie Done pour chaque équipe, l'équipe le définit elle-même. Il existe même un artefact spécial appelé DOD - Definition Of Done - il est propre à chaque équipe et y est décrit très précisément ce que signifie qu'une tâche est réalisée et qu'on peut la déplacer au statut « Done ». Le plus souvent c'est « Déployé en prod », mais il peut y avoir des nuances. Bref, d'après le graphique actuel, nous comprenons que le DOD n'est réalisé que pour une seule story, que l'équipe a estimée à 1 SP.

Le brûlage idéal montre à quel point le graphique du brûlage réel devrait se trouver en cas de travail absolument uniforme. C'est-à-dire qu'à ce moment 3 SP devraient être réalisés en cas de travail absolument uniforme.

Je soupçonne qu'il peut être intéressant de comprendre ce qu'est un Story Point. En substance, 1 SP dans une équipe et 1 SP dans une autre équipe peuvent cacher un volume de travail différent. Chez nous, par exemple, il y a des équipes avec le même nombre de personnes, mais l'une a une capacité de 17 SP par sprint, et l'autre de 35 SP. Et c'est normal. Le fait est que l'équipe choisit elle-même une tâche de référence par rapport à laquelle elle estime toutes les tâches lors des groomings (ancienne appellation - c'est la réunion hebdomadaire où le PO apporte les User Stories à estimer, et l'équipe les estime au moyen du poker de planification) (Dans SAFe c'est le PBR - Product Backlog Refinement).

Ainsi, nous pouvons avoir une User Story de référence « Moi, en tant que conducteur de voiture, je veux, après avoir fait le plein de la voiture, avoir la possibilité si nécessaire d'obtenir un reçu imprimé sur papier ». Convenir qu'elle vaut 8 SP pour notre équipe. Et lorsque le PO présente une nouvelle User Story que nous devons estimer, nous l'estimons déjà par rapport à la tâche de référence. En conséquence, la nouvelle peut déjà être estimée par l'équipe à 5 SP, par exemple, etc. toutes les stories du backlog reçoivent leurs estimations.

La capacité de l'équipe est calculée à partir des statistiques. Lors des 1-2 premiers sprints, on mesure le nombre de SP que l'équipe clôture et on calcule la valeur moyenne ; c'est sur cette valeur que se fait la planification (lorsque le PO sélectionne les tâches du sprint à partir du backlog pour une certaine capacité).

J'espère avoir suffisamment clairement décrit comment sont obtenues les valeurs sur le Burn Down Chart.