Scrum - comment reporter une User Story partiellement complète au prochain Sprint sans biaiser l'arriéré
Nous utilisons Scrum et constatons parfois que nous ne pouvons pas tout à fait terminer une User Story dans le sprint dans lequel elle a été planifiée. Dans le vrai style Scrum, nous expédions le logiciel de toute façon et envisageons d'inclure la User Story dans le prochain sprint lors de la prochaine session de planification de sprint. Étant donné que la User Story que nous reportons est partiellement terminée, comment l'estimer correctement lors de la prochaine session de planification de sprint? Nous avons considéré:
a) Ajuster le nombre de Story Points pour refléter uniquement le travail qui reste pour terminer la User Story. Malheureusement, cela gâchera de signaler le Backlog de produit.
b) Fermez la User Story partiellement terminée et montez-en une nouvelle pour implémenter le reste de cette fonctionnalité, qui aura moins de Story Points. Cela affectera notre capacité à voir rétrospectivement ce que nous n'avons pas terminé dans ce sprint et semble un peu long.
c) Ne vous embêtez pas avec a ou b et continuez à deviner pendant la planification de sprint en disant des choses comme "Eh bien, cette User Story peut être X points d'histoire, mais je sais qu'elle est terminée à 95%, donc je suis sûr que nous pouvons l'adapter."
Je suis surpris qu'il ne semble pas y avoir de réponse directe à cela. Je m'attendais à un refrain de "l'option D, factice"!
Comme nous ne semblions rien manquer d'évident, nous avons pensé que c'était l'une de ces décisions que chaque équipe devait prendre pour elle-même en fonction de la façon dont elle voulait travailler et des mesures les plus importantes pour elle.
Nous avons décidé qu'il est essentiel de conserver des enregistrements précis des user stories que nous avons mises en œuvre, car elles constituent la base de nos tests, de la documentation de support et des notes de version - ce qui exclut l'option B.
Ensuite, nous avons pensé qu'il était essentiel de pouvoir effectuer une planification de sprint avec précision - cela 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 que nous terminons partiellement dans un sprint afin de pouvoir les planifier correctement dans les sprints suivants. Au fil du temps, l'arriéré de produits rapportera légèrement le nombre de points d'histoire que nous avons mis en œuvre, mais cela posera moins de problèmes que toutes les autres options et pourrait éventuellement être résolu en modifiant notre tenue de registres et nos rapports.
Dans mon équipe actuelle, nous faisons c).
La vitesse devrait tenir compte des choses que l'équipe a vraiment terminées au sprint. Quelque chose qui n'a pas été livré n'a pas de valeur pour le client, donc nous ne comptons pas de points pour cela, c'est tout ou rien.
Nous déplaçons donc toute l'histoire inachevée au sprint suivant et tous ses points d'histoire seront ajoutés à la vitesse du sprint suivant. Les vitesses s'équilibrent avec le temps et nous prenons une moyenne des quelques sprints précédents comme référence pour déterminer les vitesses futures estimées.
L'option A est un plan d'action couramment recommandé. Vous n'attribuez pas de points pour l'achèvement de l'histoire pour le sprint précédent et pour replacer l'histoire dans le backlog de produit, où elle est redéfinie par priorité. Vous calculez votre vitesse (et d'autres mesures) en fonction des user stories terminées et de la valeur ajoutée. Lorsque vous commencez à planifier le prochain sprint, vous prenez les histoires les plus prioritaires en fonction de leur valeur (qui peut ou non inclure l'histoire inachevée, si les priorités de l'entreprise ont changé). Lorsque vous estimez l'histoire, incluez le travail qui a déjà été fait lors de la prise en compte du nouveau nombre de points pour l'histoire.
Bien sûr, une autre option (et ma préférence) serait d'utiliser le nombre estimé de points d'histoire, ce que j'ai fait dans le passé. Cela fait l'hypothèse que votre estimation était bonne et bien fondée, mais vous avez réduit trop de travail pour le sprint (par exemple, l'histoire valait en fait 3 points, mais le problème réside dans le fait que vous avez abaissé 15 points d'histoire lorsque vous n'auriez dû tirer que 13). C'est une hypothèse potentiellement dangereuse si vous n'êtes pas sûr de votre capacité à effectuer les estimations, mais cela peut fonctionner en fonction de votre équipe et de votre processus.
Cependant, vous mentionnez que cela "gâchera les rapports du Product Backlog". Le Product Backlog doit de toute façon être dynamique, les commandes et les estimations de chaque histoire changeant à mesure que l'on comprend mieux la technologie, le système, les exigences et le client. En règle générale, ce qui est rapporté du Product Backlog est le nombre d'histoires utilisateur et le nombre total de points d'histoire. Ceux-ci devraient changer à mesure que les priorités changent, de nouvelles exigences sont ajoutées, des exigences invalides sont supprimées et plus d'informations sont apprises.
En y réfléchissant trop, cela semble plus compliqué qu'il ne l'est ... C'est en fait assez simple:
Option C
Les histoires incomplètes retournent dans le backlog du 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 pouvoir l'intégrer dans le sprint, elle entre, avec son nombre de points d'origine. Sinon, il reste dans l'arriéré. Terminé. Les points sont attribués au sprint dans lequel l'histoire s'est terminée.
Si cela peut vous aider, vous pouvez suivre une métrique distincte de "travail restant" par user story, de sorte que si, à la fin du sprint, l'histoire n'est pas terminée, le travail estimé restant peut être noté sur l'histoire 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 création de rapports ne peut pas traiter l'option A avec précision, je choisirais l'option B, sauf si vous n'avez aucun espoir d'utiliser vos statistiques.
Dans certains cas, vous pouvez faire l'option B ET ne pas fausser ce que signifie la fermeture en réduisant la portée de l'ancienne tâche que vous êtes sur le point de fermer et en créant uniquement une nouvelle tâche pour la portée qui reste. Cela donne un sens sémantique à l'historique et indique généralement les endroits où vous auriez dû envisager de décomposer davantage la tâche. Parfois, ce n'est pas possible ou logique et vous avez simplement une tâche aussi grande ou qui rencontre ce niveau de problèmes.
edit: Cela suppose (comme je pense que l'OP le supposait) que le travail presque terminé n'a pas été abattu en priorité et que le fait de tirer profit de l'effort précédent le maintient suffisamment haut dans la liste pour continuer travail. Je sais que certains magasins ne le font pas, mais la plupart des endroits où j'ai travaillé envisagent de terminer une tâche restante presque complète pour être suffisamment valable pour continuer simplement à moins que quelque chose n'ait changé de façon spectaculaire. La pénalité du changement de contexte ne vaut souvent pas la peine de changer l'ordre.
Étant donné que la User Story que nous reportons est partiellement terminée, comment 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 (je pense) devrait être le plus important en ce qui concerne la vitesse d'une équipe est sa vitesse moyenne et non pas si la vitesse d'un le sprint donné montait ou descendait.
Lorsqu'une user story est définie, elle doit avoir des critères d'acceptation. Si quelque chose dans les critères d'acceptation n'est pas fait, alors 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 P.O.), alors 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 à avoir une préférence pour un scénario 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 finira par être un autre jeu de devinettes ... et n'oubliez pas que vous avez déjà obtenu le premier estimation loin. Il est probablement préférable de simplement utiliser la méthode la plus simple et de récupérer tous les points une fois qu'elle est vraiment terminée.
Pour citer M. Cohn de son livre¹ (c'est moi qui souligne):
Je suis généralement en faveur d'une position tout ou rien vers la vitesse de comptage: si une histoire est faite (codée, testée et acceptée par le propriétaire du produit), l'équipe gagne tous les points, mais si quelque chose sur l'histoire n'est pas 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; s'il manque quelque chose, ils n'obtiennent aucun point. Si l'équipe est susceptible de prendre en charge la partie restante de l'histoire dans la prochaine itération, cela fonctionne bien. Leur vitesse dans la première itération est un peu plus faible que prévu car ils n'ont obtenu aucun crédit pour avoir partiellement terminé une histoire. Dans la deuxième itération, cependant, leur vitesse sera plus élevée que prévu car ils obtiendront tous les points, même si certains travaux ont été achevé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 au fil du temps, pas à savoir si la vitesse a augmenté ou diminué au cours d'une itération donnée.
¹ Estimation et planification agiles , Réestimation des histoires partiellement terminées, p.66
Mon équipe avait précédemment tenté d'attribuer des points partiels, malgré certaines objections, et je ne pense pas que cela ait bien fonctionné du tout. (Nous ne le faisons plus ... allez comprendre) C'est particulièrement le cas parce que les histoires sont censées être estimées en équipe , mais si une seule personne travaille sur cela, il sera plus difficile pour l'équipe de savoir combien un individu a réellement accompli. Agile est plus intéressé par la vitesse moyenne d'une équipe plutôt que par l'aspect "agréable" d'un sprint particulier.
Cela étant dit, l'auteur mentionne que l'attribution de points partiels peut être envisagée s'il est peu probable que l'équipe s'attaque au travail restant lors de la prochaine itération. Dans ce cas, l'équipe estimerait le travail qui restait et le décomposait en nouvelles histoires d'utilisateurs, quelle que soit la taille qu'elles estimaient devoir avoir. Comme le mentionne l'auteur²:
Les estimations combinées n'auraient pas besoin d'être égales à l'estimation originale ...
² Idem, p.66
La meilleure recommandation pour l'équipe est de décomposer les histoires à une taille suffisamment petite pour éviter ce genre de problème³:
Cependant, les deux meilleures solutions pour attribuer des points aux 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.
Nous suivons le temps passé dans l'itération de sprint à des fins de capitalisation (heures brûlées sur les tâches liées à une user story) et déplaçons la user story pointée si l'objectif du bon de commande est de continuer à le transporter pendant le sprint suivant, en laissant pointe la même chose.
Si le but de l'OP est de déplacer quelque chose d'autre à sa place, alors nous mettrions simplement l'histoire inachevée dans l'arriéré et ferons ce qu'ils veulent. Laisser l'estimation initiale des points est ma recommandation, parce que si vous aviez l'habitude de mordre plus que vous ne pouviez mâcher, à chaque sprint, vous "complèteriez" les points d'histoire dans un sprint qui n'était pas entièrement fait et propre- articles testés.
Si vous vouliez laisser quelque chose dans le sprint, pointu ou que vous deviez expédier, je pense que vous détermineriez un point de tranche dans l'histoire originale, auquel vous avez atteint le point terminé, et que vous commettriez ce morceau plus petit pour votre itération. Ensuite, le reste pourrait être re-pointé et déposé dans le backlog. Ce serait l'occasion de réestimer car vous avez convenu avec votre équipe de diviser l'histoire en tranches.
La première question à se poser est: que signifie un point d'histoire? Si vous définissez un point d'histoire comme "Combien d'ingénierie de travail est effectuée", alors n'importe quelle réponse fera l'affaire. Cependant, si vous définissez un point d'histoire comme "Quelle valeur est apportée à l'entreprise", il devient important de ne pas accorder de crédit tant qu'une histoire n'est pas terminée, acceptée et livrée à 100%. Modifier les points d'histoire après un sprint en fonction de ce qui a été accompli ne fera que cacher le vrai problème: a) il n'y avait pas une compréhension claire de l'histoire, b) l'histoire était trop grossièrement définie, c) l'histoire manquait de critères d'acceptation mesurables, d ) pas une compréhension assez approfondie des tâches ou des dépendances pour terminer l'histoire, e) sous-estimé l'effort pour tester l'histoire, f) abattu trop de points d'histoire, ou g) ... insérez votre raison ici ...
Le but de l'agilité est d'être flexible tout en étant prévisible. La meilleure façon d'être cohérent, à mon avis, est de comprendre ce qui s'est mal passé sans modifier les estimations de l'histoire originale.