Quizz, la question 13 sur le burndown chart

La question était la suivante :

Au milieu du sprint, le burndown chart de sprint remonte. Vous êtes ScrumMaster, que faire ?

Les réponses suivantes étaient proposées :

  1. Vous regardez s’il reste du mou
  2. Vous l’envoyez immédiatement au grand chef
  3. Vous le remplacez par un burnup
  4. Vous passez un savon à l’équipe

3.9 % des 154 répondants sont partisans de tancer l'équipe. Ce n'est pas la réaction appropriée d'un ScrumMaster, dont le rôle est décrit dans cet ancien billet de presque 5 ans.

Plus de 5% sont d'avis qu'il faut en référer au chef. Comme la transparence est de mise, ce burndown devrait être visible par tout le monde y compris le grand chef, ce n'est donc pas utile de lui envoyer. De plus le burndown chart de sprint est un indicateur qui sert essentiellement à l'équipe.

Le remplacer par un burnup, choix de 13% des votants, cela semble une astuce du ScrumMaster pour masquer un mauvais indicateur. Comme on dit ce n'est pas en cassant le thermomètre qu'on guérit le malade. Cependant il est vrai que le burnup à 2 courbes est souvent plus parlant qu'un burndown, parce qu'il montre l'évolution du total en plus du reste à faire, comme le montre cet exemple de burnup de sprint en tâches. Et si le burndown remonte, c'est probablement parce que du travail a été ajouté (par exemple une tâche qui n'avait pas été identifiée avant).

C'est donc la réponse 1, plébiscitée par les quizzés, qui est la chose à faire en premier. S'il ne reste pas assez de mou, il faudra revoir les objectifs du sprint en "déscopant" une story.

Pour espérer qu'il en reste, il aura fallu, évidemment, garder du mou lors de la planification du sprint.

Là, je m'attends à une question, qu'on m'a d'ailleurs posée cette semaine au cours de ma formation Scrum de 3 jours :

il est de combien le mou ?

Commentaires

1. Le dimanche 04 décembre 2011, 21:10 par Oaz

Je prends la réponse 5 : on supprime les burndown charts car ça ne sert à rien.

2. Le lundi 05 décembre 2011, 10:32 par Dorothée

Bonjour,
Mais qu'est ce qui fait remonter un burndown ? Qu'il ralentisse, je comprends, mais pas qu'il remonte.
On a ajouté des tâches ? On en a réévalué d'autres ?

oui, ce sont 2 raisons possibles. Une autre est l'ajout d'une story.
3. Le lundi 05 décembre 2011, 18:01 par Remi

Le timeboxing est intéressant car il donne un rythme de travail , mais typiquement dans le cas de tâches non prévues en début de Sprint et si bien évidement ces tâches sont importantes dans les fonctionnalités à présenter lors de la demo , il me semble intéressant de prologer de quelques jours la durée du Sprint ! Il me semble que c'est toujours mieux que d'arriver devant le PO et de présenter un travail mal fini .

Non, on ne prolonge jamais la durée du sprint. Pour éviter d'avoir du travail mal fini, il est préférable d'enlever une (ou plusieurs) story et de bien faire les autres. Une autre remarque : ce n'est pas une bonne idée "d'arriver devant le PO" à la revue de sprint; à cette revue on ne montre que les stories déjà acceptées par le PO, pendant le sprint.
4. Le mercredi 07 décembre 2011, 09:39 par Rémi

Merci pour votre retour, OK, mais quand je parlais de tâches non prévues, c'etaient des tâches du Sprint Backlog pour réaliser des Stories acceptées par le PO qui n'avaient pas étaient identifiées lors du Sprint Meeting.

il est vrai qu'il est préférable dans la mesure du possible de supprimer des Stories pour présenter un travail finalisé.

Afin de mieux comprendre, quel élément vous dérange dans un décalage de 2j d'un Sprint de 4 semaines , si au final le PO est satisfait du résultat ?

5. Le mardi 13 décembre 2011, 22:09 par Jef

@Remi. Pratiquant le SCRUM et XP comme méthode de développement, je pense pouvoir te répondre en te disant que le rythme de travail est primordial (constant et régulier). Le rajout des quelques jours manquants est une mauvaise pratique, car elle a tendance à contraindre l'équipe à finir absolument, qui induit souvent à une mise sous pression de la part du PO et autres managers. Le fait d'être avec une date, une qualité et aussi un coût fixe (l'équipe est fixe en cours de Sprint en général et on ne gagne pas forcément à la faire grossir en cours de sprint), nous jouons sur le périmètre du Sprint. Le rythme est soutenu mais régulier et on réalise les Users Stories sur lequel on s'est engagé. L'agilité est une pratique qui se vit au quotidien et on y apprend les travers de non respect de cette méthode au fils du temps. Voilà le travers que l'on découvre avec ce genre de tentation de rallonger les Sprints.

6. Le jeudi 15 décembre 2011, 16:37 par Remi

Merci jef , je n'avais pas pensé à la contrainte de l'équipe par le PO .