Bonjour, Habr! Je vous présente la traduction de l'article
«Pourquoi je n'utilise pas de Story Points pour la planification de sprint» par Mike Cohn.
Comme décrit dans Agile Estimating and Planning, je suis un grand fan de points d'histoire pour évaluer les backlogs de produits. Cependant, je recommande également d'évaluer le backlog de sprint en heures plutôt qu'en points d'histoire. Pourquoi cette apparente contradiction? Plus tôt, j'ai écrit sur les raisons. Je recommande d'utiliser différentes unités de mesure (points et heures) pour différents arriérés.
Mais on me pose souvent une question connexe, que je veux poser ici:
Je suis curieux de savoir pourquoi vous n'utilisez pas les points d'histoire pour la planification du sprint. Je pensais que le point de mesurer la vitesse dans les points d'histoire était, en partie, de déterminer combien nous pouvons prendre (ou réparer) dans le sprint. Utilisez-vous uniquement des récits pour la planification à long terme (par exemple, la planification des versions)?Je n'utilise pas de points d'histoire pour la planification de sprint car les points d'histoire sont une mesure utile à long terme. Mais les points ne sont pas utiles à court terme.
Il serait approprié que l'équipe dise: "Nous avons une vitesse moyenne de 20 points d'histoire, et il nous reste 6 sprints, donc nous terminerons environ 120 points d'histoire dans ces six sprints."
Il serait inapproprié pour l'équipe de dire: "Nous avons une vitesse moyenne de 20 points d'histoire, nous terminerons donc au prochain sprint." Cela ne marche pas.
Supposons que l'équipe de basket-ball soit au milieu de sa saison. À ce jour, ils ont joué 41 matchs et marqué en moyenne 98 points par match. Il serait approprié de dire: "Probablement, nous marquerons une moyenne de 98 points par match dans le reste de la saison." Mais ils ne devraient pas dire avant un match en particulier: "Nous avons une moyenne de 98, donc nous en prendrons 98 aujourd'hui." C'est pourquoi je dis que la vitesse est un prédicteur à long terme utile, mais pas un prédicteur à court terme utile.
La vitesse variera d'un sprint à l'autre.
C'est pourquoi je veux que les équipes planifient leurs sprints en examinant le backlog de produit, en choisissant l'une des choses les plus importantes qu'elles pourraient faire, en divisant cet élément / histoire d'utilisateur du backlog de produit en tâches et en évaluant les tâches, en se demandant si elles peuvent prendre engagements de libérer cet article en attente du produit, puis répété jusqu'à ce qu'ils soient remplis. Pas de discussion sur les points d'histoire. Pas de discussion sur la vitesse. Ce n'est qu'une question d'obligations, et nous décidons de ce que nous pouvons accomplir en brisant les points du backlog produit en tâches et en les évaluant.
Lorsque l'équipe a fini de planifier le sprint de cette manière, il est probable que le nombre de points d'histoire qu'ils poursuivent sans le savoir soit proche de leur valeur moyenne, mais cela changera.
Il est également vrai que l'équipe effectuera environ le même nombre d'heures d'un sprint à l'autre. J'utilise le terme «capacité» pour faire référence à ce nombre d'heures, car la vitesse est réservée pour faire référence à une mesure du volume de travail planifié ou terminé, comme indiqué dans les unités utilisées pour évaluer le carnet de produit (que je recommande d'utiliser des points d'histoire )
À propos de l'auteur: Mike Cohn est l'un des auteurs de la méthodologie de développement logiciel Scrum. Il est l'un des fondateurs de l'Agile Alliance et de la Scrum Alliance. Il se spécialise dans l'aide aux entreprises pour mettre en œuvre et améliorer l'utilisation de processus et de méthodes agiles pour créer des équipes performantes.
Références:
Agile Estimating and Planning , Mike Cohn, 2005.
PS Évaluez-vous le backlog de sprint en heures ou en points d'histoire?