Agile Gardener

À maintes reprises ces derniers mois, j’ai dû répondre à la question qui tracasse beaucoup d’équipes et de Product Owner (PO) lorsqu’ils viennet d’échouer une ou plusieurs stories :

Faut-il réestimer les stories refusées lorsqu’on les prend dans l’engagement du sprint suivant?

Je demande alors ce qui fait sens pour eux. Quelle information tirent-ils de l’estimation d’une storie? Qu’est-ce qui serait le plus pertinent pour réussir le prochain sprint puisque le dernier vient d’échouer?

Les réponses varient bien évidemment, mais le plus important est alors de déclencher avec l’équipe une conversation autour de la notion de vélocité¹, de son utilité, de son utilisation. Cette discussion ne fait pas l’objet du billet d’aujourd’hui mais j’y reviendrai éventuellement (au sens québécois du terme ) dans un prochain billet.

L'allure générale du burndown va varier en fonction de votre façon de gérer les stories échouées à la fin d'un sprint

Aujourd’hui je souhaite principalement partager ma pratique actuelle. Je dis actuelle car ma réflexion et ma préconisation ont évolué au cours du temps.

Actuellement, au moment de la planification d’un sprint, je préconise à l’équipe de réestimer les stories et de mettre à jour le backlog pour refléter l’effort nouvellement évalué. Cette façon de faire à les effets  suivants :

• lisser la vélocité,
• réduire le volume global du backlog, (sur l’instant bien entendu car j’exclus ici la création de story ou la réévaluation de story précédemment estimées, etc),
• perdre l’historique de l’effort initialement estimé pour la story.

Dans le passé, je ne réestimais pas les stories au moment du sprint, l’équipe évaluait ou plutôt devrais-je dire pariait, comme pour un premier sprint, sur le ‘volume’ des stories qu’elle pensait être capable de réaliser. Cette façon de faire avait les effets suivants :

• générer des fluctuations parfois importantes de la vélocité, pour finalement calculer une moyenne sur le long terme,
• rendre l’engagement très aléatoire, l’équipe n’avait pas de repère (vélocité précédente) et pariait sur un engagement, comme lors d’un tout premier sprint,
• conserver le volume du backlog tel qu’initialement estimé (sans faire entrer ici d’autres considérations telles que la réestimation des stories déjà estimées au cours des planifications de release précédentes, la division d’une story en plusieurs, la création de stories,…),
• maintenir l’historique de l’effort estimé pour la story.

J’ai aussi vu une troisième méthode qui consistait à réestimer ‘oralement’ le reste-à-faire (en story points), mais sans mettre à jour le backlog. Cela permettait de prendre un engagement raisonnable car il incluait le nouvel effort estimé, mais l’engagement affiché était lui très généreux, reprenant l’effort estimé au sprint passé et non mis à jour!

Comme je vous le disais plus tôt la discussion autour de la notion de vélocité était intéressante. Pourquoi réestimer sans mettre le backlog à jour? Mystère! Un bon sujet pour un prochain billet.

Afin de partager vos pratiques, je vous propose de répondre au sondage suivant. Et surtout n’hésitez pas à partager votre expérience en laissant un commentaire.

 Loading ...