Burndown chart de release

[Kagilum]

Bonjour,

Pouvez vous m’expliquer comment fonctionne le burndown chart de release dans IceScrum ?

Pour chaque sprint, de quelles Stories proviennent les points affichés ? Est-ce qu’il s’agit des points de Stories déclarées avant le sprint (capacité estimée) ou de Stories “Done” (vélocité) ?

D’après mes observations il s’agit des stories déclarées avant chaque début de sprint. Dans ce cas en quoi ce diagramme peut-il nous donner l’avancement du projet ?

[Nicolas Noullet]

Bonjour,

Vos observations sont correctes : chaque barre du burndown représente le nombre total des points des stories non finies, c’est à dire l’effort qu’il reste à fournir pour terminer le projet.

Il y a une barre par sprint, l’indicateur représente donc l’évolution du reste à faire global du projet sprint après sprint. C’est donc bien une manière de mesurer l’avancement du projet ! On mesure simplement cet avancement par ce qu’il reste à faire (c’est l’objet du burndown), l’autre moyen étant de mesurer l’avancement par ce qui est fait (c’est l’objet du burnup).

Afin d’obtenir un point dans le graphique dès le début du projet (au début du premier sprint), la valeur est capturée à l’activation des sprints.

C’est au même moment qu’est capturé la capacité du sprint. L’équipe espère alors faire diminuer le nombre de points à faire total du projet à hauteur de la capacité du sprint et faire descendre le burndown. Cependant, ceci ne sera pas forcément le cas pour deux raisons :
– Certaines stories ne seront pas finies : seule la vélocité, c’est à dire les points des stories finies, viendra réellement diminuer le total du reste à faire du projet.
– De nouvelles stories pourront être estimées, ajoutant leurs points au total qui sera capturé à la prochaine barre du burdown. Si on veut s’abstraire de cela pour se focaliser sur le travail de l’équipe, on préférera donc l’indicateur capacité vs. vélocité.

Les indicateurs ont vocation de rendre visible les éléments clé du projet. Cette visibilité doit alors être exploitée par le Scrum Master, les parties prenantes et l’équipe. L’interprétation des indicateurs doit prendre en compte le contexte du projet pour être pertinente.

Par exemple, l’équipe est face à un burndown relativement constant au fil des sprints :
– Si les stories sont relativement bien connues et estimées en début de projet / release, alors le burndown constant indique que l’équipe n’avance pas suffisamment et que le projet risque d’échouer. Des actions doivent donc être décidées pour prévenir ce risque.
– Si le backlog est très vivant et de nouvelles stories sont estimées régulièrement alors le burndown constant indique que l’équipe fait bien avancer le projet : autant de points sont produits que de points sont rajoutés au backlog, équilibrant le total des points à produire.

[Kagilum]

Bonjour Nicolas,

Merci pour ces éléments.
Pour bien comprendre, est-ce que le nombre de points déclarés sur ce graphe représentent la somme des stories non finies et déclarées dans le plan de release (menu plan de release) à la fin de chaque sprint ?
Pouvez vous me confirmer qu’il ne s’agit pas de la somme des stories non finies dans le Product Backlog ?

[Nicolas Noullet]

Comme je l’ai indiqué précédemment, il s’agit des valeurs en début de sprint et non fin de sprint.

C’est le total des estimations des stories non finies (backlog + plan de release) qui est utilisé que ce soit dans le burndown de release ou celui de produit. Celui de release apporte peu de valeur si ce n’est un “focus” sur les sprints de la release en cours.

Je ne suis pas à l’origine de cette décision mais j’imagine que le postulat était que toutes les stories estimées ont vocation d’être planifiées dans la release courante (sauf peut être au dernier sprint de la release en cas de continuité immédiate entre les deux releases ?).

Merci pour vos retours en tous cas, ils démontrent que ceci mériterait d’être clarifié dans l’outil. Ceci renforce notre volonté d’améliorer les indicateurs en leur adjoignant des indications sur la manière dont ils sont générés et comment les interpréter.

[Kagilum]

Merci pour ces informations, je comprends mieux comment cet indicateur est généré.

Il me semble tout de même que cette façon de générer ce graphe pose 2 problèmes :

– A la fin d’un sprint, le graphe n’indique pas le reste à faire. Il faut démarrer un nouveau sprint pour le savoir (comment faire lorsqu’il s’agit du dernier sprint ?). Le graphe donne donc l’évolution du projet avec une vision “sprint N-1”. Est-ce que le principe d’un burndown n’est pas de se mettre à jour à la fin d’un cycle afin de montrer ce qui est “Done” (fin de journée, fin de sprint, fin de release) ?

– En prenant toutes les stories estimées, le graphe mélange les stories de la release et les stories de la backlog pouvant être estimées par anticipation des futurs releases. Il faut donc s’interdire d’estimer des Stories de la backlog (non prévues dans la release courante) pour ne pas fausser cet indicateur si l’on souhaite rester au niveau “release”.

[Nicolas Noullet]

Concernant le premier point, le burndown sert à montrer le travail restant et c’est particulièrement intéressant quand on commence à travailler (burndown de projet avec une capture en début de sprint) et pour suivre l’avancée du travail (burndown de sprints avec une capture par jour) plutôt qu’en fin de cycle (à la fin du Sprint par ex. où on se concentre effectivement sur le Done, qui est l’objet d’autres indicateurs). Si il s’agit de la fin du dernier sprint du projet alors il n’y a à priori pas d’objet à se concentrer sur le travail restant, ce qui compte c’est ce que contient le produit réalisé. Je pense que c’est cela qui a guidé le choix d’implémentation dans iceScrum (je ne travaillais pas encore sur iceScrum à ce moment là et je suppose, sans garantie, que c’est le Product Owner d’alors, Claude Aubry, qui a suggéré ce comportement).

Concernant le deuxième point, c’est une bonne pratique d’anticiper l’estimation des stories (point trop n’en faut bien sûr), et dans le cas de releases qui se suivent sans pause c’est effectivement un problème, l’outil ne devrait obliger à “s’interdire” d’estimer des stories.

[Author]

Posts