Scrum - comment reporter une user story partiellement complète sur le prochain sprint sans fausser l'arriéré

Nous utilisons Scrum et constatons parfois que nous ne pouvons pas terminer une histoire d'utilisateur dans le sprint dans lequel elle était planifiée. Dans le vrai style Scrum, nous livrons quand même le logiciel et envisageons d'inclure la user story dans le prochain sprint lors de la prochaine session de planification de sprint. Etant donné que la user story que nous reportons est partiellement terminée, comment pouvons-nous l'estimer correctement lors de la prochaine session de planification de sprint? Nous avons considéré:

a) Ajustez le nombre de points d’histoire pour refléter uniquement le travail qui reste à accomplir pour compléter l’histoire utilisateur. Malheureusement, cela va gâcher de rapporter le backlog de produit.

b) Fermez la user story partiellement complétée et créez-en une nouvelle pour implémenter le reste de cette fonctionnalité, qui aura moins de points de story. Cela affectera notre capacité à voir de manière rétrospective ce que nous n’avons pas accompli dans ce sprint et semble prendre un peu de temps.

c) Ne vous embêtez pas avec a ou b et continuez à deviner pendant la planification du sprint en disant: "Cette histoire d'utilisateur est peut-être une histoire X, mais je sais qu'elle est terminée à 95%, donc je suis sûr que nous pouvons l'intégrer."

Dans mon équipe actuelle on fait c).

La vélocité devrait rendre compte des choses que l'équipe a vraiment terminées dans le sprint. Quelque chose qui n'a pas été livré n'a aucune valeur pour le client, nous ne comptons donc pas de points, c'est tout ou rien.

Nous reportons donc toute l'histoire inachevée sur le prochain sprint et tous ses points d'histoire seront ajoutés à la vitesse du prochain sprint. Les vitesses s’équilibrent avec le temps et nous prenons la moyenne des quelques sprints précédents comme référence pour déterminer les vitesses futures estimées.

L'option A est une procédure couramment recommandée. Vous n'attribuez pas de points à l'achèvement du récit du sprint précédent et ne le réintroduisez pas dans le carnet de produit, où il est redéfini les priorités. Vous calculez votre vélocité (et d'autres métriques) en fonction des user stories complétées et de la valeur ajoutée. Lorsque vous commencez à planifier le prochain sprint, vous prenez les récits de priorité la plus élevée en fonction de leur valeur (qui peut ou non inclure le récit inachevé si les priorités de l'entreprise ont changé). Lorsque vous estimez l’histoire, incluez le travail déjà effectué lors de la prise en compte du nouveau nombre de points de l’histoire.

Bien sûr, une autre option (et ma préférence) consisterait à utiliser le nombre estimé initial de points de scénario, ce que j'avais déjà fait par le passé. Cela laisse supposer que votre estimation était bonne et fondée, mais que vous aviez trop de travail pour le sprint (par exemple, l’histoire valait en réalité 3 points, mais le problème réside dans le fait que vous en avez retiré 15 vous devriez avoir seulement tiré 13). C'est une hypothèse potentiellement dangereuse si vous n'êtes pas confiant dans votre capacité à effectuer les estimations, mais cela peut fonctionner en fonction de votre équipe et de votre processus.

Toutefois, vous indiquez que cela va "gâcher la création de rapports sur le backlog du produit". Le backlog de produit doit de toute façon être dynamique, la commande et les estimations de chaque récit évoluant au fur et à mesure que l'on en comprend plus sur la technologie, le système, les exigences et le client. Généralement, ce qui est signalé dans le backlog de produit est le nombre de récits d'utilisateurs et le nombre total de points de récits. Celles-ci devraient être modifiées au fur et à mesure que les priorités changent, que de nouvelles exigences sont ajoutées, que des exigences non valides sont supprimées et que des informations supplémentaires sont apprises.

Si on y réfléchit trop, cela semble plus compliqué que ça ne l'est vraiment ... C'est en fait assez simple:

Option C

Les histoires incomplètes sont remises dans le carnet de produit sans que les points soient modifiés. Lors de la planification du prochain sprint et de ce qui peut être fait, la discussion devrait inclure le fait qu'une grande partie du travail est déjà accomplie. Si l’équipe décide de l’intégrer au sprint, elle entre avec le nombre de points initial. Sinon, il reste dans l'arriéré. Terminé. Les points sont attribués au sprint dans lequel l’histoire a été complétée.

Si cela vous aide, vous pouvez suivre une métrique "travail restant" distincte par récit utilisateur, de sorte que si, à la fin du sprint, le récit n'est pas terminé, le travail estimé restant peut être noté dans le récit et pris en compte lorsque planifier son inclusion dans un sprint ultérieur. Mais même dans ce cas, ne modifiez pas la valeur en points de l'histoire originale.

Si votre outil de génération de rapports ne peut pas gérer l’option A avec précision, j’utiliserais l’option B à moins que vous n’ayez aucun espoir d’utiliser jamais vos métriques.

Dans certains cas, vous pouvez utiliser l'option B ET ne pas biaiser le sens de close en rétrécissant la portée de l'ancienne tâche que vous êtes sur le point de fermer et en ne créant qu'une nouvelle tâche pour la portée restante. Cela rend l’historique plus logique du point de vue sémantique et indique généralement les endroits où vous auriez dû envisager de décomposer davantage la tâche. Parfois, cela n’est ni possible ni logique et vous avez simplement une tâche aussi importante que celle que vous rencontrez.

edit: Cela suppose (comme le PC le supposait supposé) que le travail presque terminé n’a pas été déclassé en priorité et que le fait de tirer profit de l’effort précédent le maintient suffisamment haut dans la liste pour continuer à fonctionner. Je sais que certains magasins ne le font pas, mais la plupart des endroits dans lesquels j'ai travaillé considèrent que terminer une tâche restante presque complète est suffisamment précieux pour continuer simplement, à moins que quelque chose ait changé de façon spectaculaire. La pénalité de changer de contexte ne vaut souvent pas la peine de changer l'ordre.

Etant donné que la user story que nous reportons est partiellement terminée, comment pouvons-nous l'estimer correctement lors de la prochaine session de planification de sprint?

Je ne pense pas que les options A à C soient bonnes, principalement parce que ce qui devrait (à mon avis) être le plus important en ce qui concerne la vitesse d’une équipe est sa vitesse moyenne et non pas le fait que la vitesse d’un sprint donné augmente ou diminue.

Lorsqu'une user story est définie, elle devrait avoir des critères d'acceptation. Si quelque chose ne figure pas dans les critères d'acceptation , l'équipe ne gagne tout simplement aucun des points. Si l'histoire est terminée (c'est-à-dire codée, testée et acceptée par le bon de commande), l'équipe obtient tous les points.

Cela fonctionne bien lorsque l'équipe se concentre sur sa vitesse moyenne plutôt que sur la vitesse d'un sprint donné.

Comme M. Cohn dans son livre, j'ai tendance à préférer le scénario du tout ou rien. Après tout, essayer d’estimer si vous avez terminé 5 points sur une histoire de 8 points, ou peut-être seulement 6 ou 7, va devenir un autre jeu de devinettes ... et n'oubliez pas que vous avez déjà reçu le premier estimer la distance. Il est probablement préférable d’utiliser la méthode la plus simple et d’obtenir tous les points une fois celle-ci complétée.

Citant M. Cohn de son livre¹ (je souligne):

Je suis généralement favorable à une position du tout ou rien en ce qui concerne la vitesse de comptage: si une histoire est créée (codée, testée et acceptée par le propriétaire du produit), l'équipe gagne tous les points, mais si quelque chose dans l'histoire pas fait, ils ne gagnent rien. À la fin d'une itération, c'est le cas le plus facile à évaluer: si tout est fait, ils obtiennent tous les points; si quelque chose manque, ils ne reçoivent aucun point. Si l'équipe est susceptible d'assumer la partie restante de l'histoire lors de la prochaine itération, cela fonctionne bien. Leur vélocité lors de la première itération est un peu inférieure aux attentes car ils n’ont aucun crédit pour avoir partiellement terminé un récit. Lors de la deuxième itération, toutefois, leur vitesse sera supérieure à celle attendue car ils obtiendront tous les points, même si certains travaux ont été terminés avant le début de l’itération.Cela fonctionne bien tant que tout le monde se souvient que nous nous intéressons principalement à la vitesse moyenne de l'équipe dans le temps, et non au fait que la vitesse augmente ou diminue d'une itération donnée.

¹ Estimation et planification agiles , réestimation des récits partiellement terminés, p.66

Mon équipe avait déjà tenté d’attribuer des points partiels, malgré certaines objections, et je ne pense pas que cela ait bien fonctionné. C’est particulièrement le cas, car les histoires sont supposées être estimées en équipe . Cependant, si une seule personne travaille dessus, il sera plus difficile pour l’ équipe de savoir combien une personne a effectivement terminé. Agile s'intéresse davantage à la vitesse moyenne d'une équipe qu'à la "beauté" d'un sprint particulier.

Cela étant dit, l'auteur fait mention que l' attribution d'une partie des points peut être envisagée que si l'équipe est peu susceptible d'aborder le travail restant dans la prochaine itération. Dans ce cas, l'équipe devrait estimer le travail restant et le décomposer en nouvelles histoires d'utilisateurs, quelle que soit leur taille. Comme le mentionne l'auteur²:

Les estimations combinées n'auraient pas besoin d'égaler l'estimation initiale ...

² Idem, p.66

La meilleure recommandation pour l'équipe est de réduire les histoires à une taille suffisamment petite pour éviter ce genre de problème³:

Cependant, les deux meilleures solutions pour attribuer des points à des histoires incomplètes sont de ne pas avoir d'histoires incomplètes et d'utiliser des histoires suffisamment petites pour que le crédit partiel ne soit pas un problème.

³ Idem, p.67

J'espère que cela t'aides.

Je suis surpris qu'il ne semble pas y avoir de réponse directe à cette question. Je m'attendais à un refrain de "l'option D, factice"!

N'ayant rien manqué d'évident, nous avons pensé que c'était l'une des décisions que chaque équipe devait prendre pour elle-même en fonction de la manière dont elle voulait travailler et des paramètres qui lui importaient le plus.

Nous avons décidé qu'il était essentiel de conserver des enregistrements précis des user stories que nous avons implémentées, car celles-ci constituent la base de nos tests, de la documentation de support et des notes de publication - ce qui exclut l'option B.

Ensuite, nous avons déterminé qu’il était essentiel de pouvoir planifier les sprints avec précision - ce qui exclut l’option C.

Nous avons donc conclu que l’option A nous convient. Nous allons ré-estimer les points d'histoire pour toutes les histoires partiellement complétées lors d'un sprint afin de pouvoir les planifier correctement lors des sprints suivants. Au fil du temps, l'arriéré des produits sous-traitera légèrement le nombre de points de récits que nous avons mis en œuvre, mais le problème sera moins grave que celui de toutes les autres options et pourrait éventuellement être résolu en modifiant notre comptabilité et nos rapports.

Nous suivons le temps passé dans l'itération du sprint à des fins de capitalisation (heures consacrées à des tâches liées à une user story) et déplaçons la user story pointue si l'objectif du bon de commande est de continuer à le camionner lors du prochain sprint, en laissant pointe le même.

Si l'objectif du bon de commande est de déplacer quelque chose d'autre à sa place, nous ajouterions simplement l'histoire inachevée à l'arriéré et ferions tout ce qu'ils voudraient. Ma recommandation est de laisser l'estimation initiale des points, car si vous aviez l'habitude de mordre plus que vous ne pouviez en mâcher, à chaque sprint, vous "compléteriez" les points de l'histoire dans un sprint qui n'était pas complètement fait et propre. articles testés.

Si vous vouliez laisser quelque chose dans le sprint, pointu ou que vous deviez expédier, je penserais que vous détermineriez un point de tranche dans l'histoire originale, pour lequel vous avez atteint le point final, et engagez ce petit morceau pour votre itération. Ensuite, le reste pourrait être réorienté et ajouté à l'arriéré. Ce serait une occasion de faire une nouvelle estimation car vous avez convenu avec votre équipe de diviser l’histoire en plusieurs parties.

La première question à poser est Qu'est-ce qu'un point de récit? Si vous définissez un point de récit comme "combien de travail d'ingénierie est effectué", alors toute réponse fera l'affaire. Toutefois, si vous définissez un point d'histoire comme "Quelle est la valeur apportée à l'entreprise", il devient important de ne pas donner de crédit tant qu'une histoire n'est pas terminée, acceptée et livrée à 100%. La modification des points d’histoire après un sprint en fonction de ce qui a été achevé ne fera que masquer le vrai problème: a) l’histoire n’était pas bien comprise, b) l’histoire était trop grossièrement définie, c) l’histoire manquait de critères d’acceptation mesurables, d ) ne comprenez pas suffisamment les tâches ou les dépendances pour compléter l’histoire, e) minimisez l’effort de tester l’histoire, f) réduisez trop de points d’histoire, ou g) ... insérez votre raison ici ...

Le but de l'agile est d'être flexible tout en étant prévisible. La meilleure façon d'être cohérent, à mon avis, est de déterminer ce qui ne va pas sans modifier les estimations originales.