Surestimation Scrum et replanification

Nous sommes au milieu de notre premier Sprint et quelque chose se lève sur nous: nous avons surestimé!

Nous avions prévu 114 heures idéales pour cette itération de 2 semaines et à la fin de la première semaine, nous avons terminé tout le Sprint. Qu'est-ce qu'on fait maintenant? Le «livre» indique que nous devrions et nous obtiendrons les prochains éléments de haute priorité de l'arriéré. Cependant, comment les ajouter au tableau de gravure? La réécrivons-nous pour rendre compte de ces histoires comme si elles étaient là depuis le début? Ou simplement ajouter leurs estimations à l'axe des y le jour où nous commençons à travailler dessus (montrant un saut d'angle de 90 °)?

Toute rétroaction est la bienvenue!

L'un des objectifs de disposer d'un tableau de répartition est de montrer comment, au fil du temps et de manière transparente, la valeur est offerte.

Les nouvelles histoires d'utilisateurs n'étaient pas dans le sprint au début, il semble donc quelque peu délicat de prétendre qu'elles l'étaient. En les ajoutant dans le graphique de burndown à ce moment, vous montrez avec précision que le niveau actuel d'estimation est encore quelque peu dans ses phases d'évolution préliminaires.

C'est bon pour vous et pour votre propriétaire de produit. Il montre et montrera comment l'utilisation de ce système de gestion de projet vous a permis de devenir de meilleurs estimateurs.

Vous pourrez voir dès le début que vous étiez surestimé, puis sous-estimé, puis surestimé un peu plus mais légèrement moins ... et finalement vous verrez les améliorations de l'estimation au fur et à mesure.

Je pense que l'estimation des user stories est l'une des parties les plus difficiles d'un sprint et ce n'est qu'une fois que votre équipe apprendra à évoluer ensemble qu'elle deviendra de plus en plus efficace dans le processus. Il est bon que cela soit démontré à l'aide des outils que vous utilisez, tels que le tableau de gravure.

Cela ne fera pas de mal si vous annulez le sprint et planifiez le prochain sprint en tenant compte de votre vitesse actuelle.

Du guide Scrum officiel :

Les sprints peuvent être annulés avant la fin de la zone de temps. Seul le Product Owner est autorisé à annuler le Sprint, bien qu'il puisse le faire sous l'influence des parties prenantes, de l'équipe ou du ScrumMaster.

Étant donné que la planification du sprint doit être effectuée dans le cadre d'une discussion avec le propriétaire du produit, le Scrum Master et l'équipe, il serait contre-productif de simplement choisir les prochaines histoires d'utilisateurs.

Dans le cas où vous étiez légèrement en avance, vous auriez pu choisir la prochaine histoire prioritaire, mais ici votre situation est très différente.

Vous pouvez ajouter un graphique de gravure . Ils montrent, sans ambiguïté, quand et combien de nouveaux travaux vous avez ajoutés:

Ce graphique montre que l'équipe a ajouté 20 points de travail supplémentaires dans l'itération 5. Cette image montre les itérations, mais cela fonctionne aussi bien avec les jours.

Il existe un certain nombre de techniques différentes pour visualiser cela.

L'une d'elles consiste à introduire un décalage par rapport à l'axe des y (l'axe horizontal) le jour où les nouvelles histoires ont été ajoutées, le graphique de gravure réel passant alors en dessous du niveau "0" d'origine.

Une autre consiste à prétendre qu'ils étaient là depuis le début (ce qui est beaucoup plus facile si vous utilisez des graphiques de gravure basés sur CGI).

Et vous pourriez créer le vôtre.

La chose la plus importante est d'en discuter entre l'équipe, le Scrum Master et le Product Owner pour parvenir à un accord sur ce que vous voulez faire dans cette situation. Il n'y a aucun moyen absolument fixe de faire quoi que ce soit en mêlée autre que les règles de base. Scrum est censé évoluer au fil du temps pour s'adapter au mieux aux besoins de votre environnement.

Je voudrais décomposer le problème du PO en trois questions distinctes:

1. Continuer ou annuler le sprint?
2. Que faire la semaine restante si le sprint continue?
3. Comment planifier le prochain sprint?

Les graphiques de combustion et de combustion mentionnés dans d'autres questions, bien qu'utiles, sont secondaires par rapport au PO "que faisons-nous maintenant?"

Continuer ou annuler : je suis avec Pierre ici, il convient d'annuler ce sprint et de commencer à planifier le prochain immédiatement. L'annulation de sprint n'est pas une option s'il y a d'autres équipes et les sprints doivent être synchronisés (la plupart des gourous de Scrum conseillent de les synchroniser).

Si le sprint continue: Limitez le travail en cours . Travaillez sur une seule histoire à la fois, concentrez-vous sur la finition, pour laquelle vous avez moins d'une semaine. Assurez-vous qu'il n'y a pas d'histoires partiellement terminées à la fin du sprint.

Comment planifier le suivant : les options ici sont d'essayer l'estimation de la taille relative ou d'utiliser l'équivalence jour-personne-personne et le facteur de focalisation comme approximation comme décrit dans le livre de Henrik Kniberg "Scrum and XP from the Trenches". Nous en avons déjà discuté dans un fil de discussion différent.

Être achevé dans la moitié du temps est une énorme variation par rapport aux estimations. Pour moi, cela indiquerait un risque important que ce que votre équipe a réellement fait s'écarte de ce que les utilisateurs attendaient au début du Sprint. En outre, un Sprint est également censé fournir suffisamment de fonctionnalités pour qu'il soit maintenant temps pour de nouveaux commentaires du PO.

Donc, le risque de simplement saisir des choses du haut du PB et de continuer est que ces éléments en haut du PB sont obsolètes (à la fois en termes de contenu et de priorité), et que votre équipe s'est trompée lors du dernier Sprint. et vous vous contenterez de tirer parti de ces erreurs sans obtenir de commentaires du PO.

Je dirais que la façon la plus raisonnable de procéder est d'appeler le Sprint terminé, de tenir votre examen de fin de Sprint habituel, de planifier une réunion et une rétrospective et de commencer le prochain Sprint.

En ce qui concerne le graphique du burndown, la question d'origine semble manquer de savoir à quoi elle sert. C'est vraiment juste un outil pour déterminer si vous avez un problème avec la progression pendant votre Sprint. Avec ce qui a été décrit, le tableau de burndown aurait dû entrer en jeu dans cette situation vers le jour 2 ou 3 du Sprint, alors qu'il aurait montré que l'équipe était bien en avance sur les tâches de sprint. Ensuite, vous posez la question "Pourquoi?", Et déterminez si vos estimations étaient loin ou si les programmeurs interprètent mal les tâches, ou si quelque chose déraille d'une manière ou d'une autre.

Mais lorsque vous ignorez le tableau de gravure et continuez comme s'il n'y avait rien d'étrange, il semble que vous le traitiez simplement comme un artefact inutile que vous produisez parce que le "livre" vous le dit. À mon avis, si vous décidez de simplement retirer quelques trucs du haut du PB et de continuer pendant la deuxième semaine, alors commencez simplement un nouveau burndown pour la deuxième semaine (et alors vous pouvez ignorer comme vous avez fait celui pour la première semaine).

Je consulterais le propriétaire du produit sur le travail à faire et je l'ajouterais au sprint actuel à la date à laquelle le travail a été introduit. On peut suivre le travail ajouté sur le tableau de gravure. Je n'ai pas de problème avec un graphique de gravure qui ressemble un peu à des montagnes russes. Cela se produira de toute façon car les membres de la mêlée estiment le temps restant sur les tâches.