Avec Agile, que faire lorsqu'une user story n'est pas terminée dans une itération?
Déplacez-vous simplement l'histoire vers une nouvelle itération ou retardez-vous la prochaine itération?
Cela devient un peu délicat lorsque vous utilisez quelque chose comme Jira lorsque vous devez copier ou déplacer des histoires entre les itérations car cela affecte les calculs de vitesse/points, etc.
Existe-t-il une meilleure pratique?
D'après mes expériences, les histoires sont terminées ou non. Il n'y a aucun concept d'une histoire inachevée. À la fin d'un sprint, vous avez soit terminé la conception, l'implémentation, les tests, l'intégration et les tests du système pour une histoire et l'avez présentée au client pour approbation, date à laquelle elle a été retirée du carnet de commandes ou est restée dans l'arriéré pour le prochain sprint. Il n'y avait aucun concept de réestimation ou d'histoires partiellement terminées.
Au début de la prochaine itération, une histoire à N points qui avait été lancée lors de l'itération précédente et qui était restée inachevée était toujours considérée comme une histoire à N points. Notre vitesse pour le sprint précédent a été utilisée pour abaisser un nombre approprié de points d'histoire pour le sprint suivant, en commençant par les N points inachevés et les étages supérieurs jusqu'à ce que le nombre de points d'histoire dans l'itération soit la vitesse des points précédents.
Cependant, c'était juste notre pratique. La clé est d'être cohérent. Quoi que vous choisissiez, faites-le à chaque itération et ne changez pas - cela affectera la façon dont vous calculez la vitesse et estimez le travail pour les futurs sprints.
La taille de l'itération est censée être fixe. La meilleure approche (selon moi :)) est de se séparer. Généralement, lorsque les tâches ne sont pas terminées dans l'itération à laquelle elles sont affectées, je suggère de fractionner les user stories et de déplacer les tâches incomplètes vers l'itération suivante. L'estimation de la nouvelle user story est calculée à partir des unités restantes nécessaires pour compléter la user story originale. De cette façon, vous pouvez conserver les estimations et également conserver les références historiques.
Déplacez l'histoire à la prochaine itération. Peut-être mettre à jour sa taille, si un gros travail a été fait dessus.
A. Mettez l'histoire dans l'arriéré du projet. Si c'est toujours la chose la plus importante, elle sera programmée pour le prochain sprint. Sinon, le propriétaire du produit planifiera quelque chose de plus précieux.
B. Vous n'obtenez aucun point pour cette histoire pour ce sprint. Lorsque vous planifiez le prochain sprint, ne comptez que les points pour les histoires terminées ce sprint. (Oui, vous tirerez une histoire bonus à la fin du prochain sprint. Génial. Mais il vaut mieux obtenir une histoire bonus que de présumer que vous l'avez fait, alors vous aurez une autre histoire inachevée à expliquer. .)
Vous pouvez déplacer l'histoire à la prochaine itération et effectuer une nouvelle estimation. Vous pouvez toujours discuter avec le propriétaire du produit/l'équipe et le maître de mêlée de ce qu'il faut faire.
Le dilemme: où vont les points d'histoire pour les histoires inachevées? Le sprint où ils sont finis? Crédit partiel dans chaque sprint pour la portion terminée à chaque sprint? Voici comment j'ai répondu au dilemme dans un article de blog:
Ces points ne vont nulle part. Pas de crédit. Mais l'équipe DOIT terminer le travail.
Blog complet sur ce sujet ici: http://agileangle.blogspot.com/2011/07/story-points-who-gets-credit.html
En plus d'autres réponses, vous pourriez
1) créer une histoire pour représenter le travail terminé et une nouvelle pour le travail restant, en ajustant les estimations.
2) analyser les raisons d'une erreur d'estimation. Les histoires représentent généralement des engagements, et si un engagement n'a pas été respecté, c'est plutôt mauvais. N'y avait-il pas suffisamment d'analyses au départ (c'est-à-dire que les développeurs ne savaient pas combien de travail cela représenterait réellement), les gens sont-ils tombés malades, d'autres bogues ont-ils empêché le travail d'être fait, etc.?
Si l'histoire n'est pas terminée (comme dans votre définition de terminé), vous ne devriez pas en recevoir de points.
Dans le sprint suivant, créez une nouvelle histoire basée sur ce qui reste de l'inachevé, ajoutez-le au backlog du sprint et estimez-le. Possibilité de le fusionner avec une autre histoire s'il est trop petit.
Si votre outil ne peut pas gérer cela, vous devriez probablement chercher quelque chose qui le peut. Je préfère outils low-tech moi-même.
Nous avons tendance à essayer de freiner les histoires afin qu'elles puissent facilement s'insérer dans un sprint et qu'elles puissent être facilement supprimées. Il faut un certain état d'esprit pour briser l'histoire en morceaux livrables lors de la réunion de planification du sprint.
La chose que j'ai également trouvée est que si les histoires se décomposent en éléments livrables (qui peuvent être visibles ou non, ou même désactivés pour quelques sprints), mon équipe peut faire tout le travail sur le tronc, et pas de tracas à faire travailler sur une branche, puis rebaser/fusionner le travail plus tard, ce qui est toujours pénible, c'est donc un bonus.
Nous faisons une variation sur certaines des réponses données.
Vous estimez un sprint à un nombre donné de points, disons 34. Si après avoir atteint le point final désigné pour le sprint et que nous n'avons pas terminé, nous entrons dans un sprint correctif.
Cela signifie:
- Nous obtenons un crédit pour les 34 points.
- Nous devons terminer l'histoire sur laquelle nous travaillions. C'était la priorité la plus élevée sur l'arriéré au moment de l'affectation, de sorte qu'il maintient cette priorité.
- Nous chargeons et travaillons sur l'histoire donnée jusqu'à ce que nous rencontrions notre définition du fait. Cette quantité de temps est attribuée à 0 point d'histoire. Cela sert à ajuster notre vitesse.
- Lors de la revue de sprint, le Product Owner, en consultation avec l'équipe de sprint et les parties prenantes, prend la décision sur le fait. Dans ce cas, le bon de commande déclare que l'histoire ne répondra pas aux besoins du client comme prévu.
- Le bon de commande peut choisir de créer une nouvelle histoire et de la placer dans le backlog Produit. La nouvelle histoire, comme toute histoire, est basée sur les informations dont dispose le bon de commande sur l'état actuel du produit et les besoins actuels du client. Cela inclut évidemment la discussion qui a eu lieu sur l'histoire non terminée ci-dessus.
- Lors de la prochaine réunion de planification, la nouvelle histoire est évaluée comme les autres. Le PO donne la priorité et l'équipe estime l'effort.
Remarques:
- Le degré de réussite est un facteur dans le processus de décision. Par exemple, si l'équipe convient qu'elle est "à une heure" de la fin, l'OP peut accepter de retarder la décision prise. Mais l'équipe doit encore démontrer que l'histoire est terminée!
- Dans mon équipe, une histoire n'est jamais déplacée hors du sprint après la révision des sprints (elle est fermée telle quelle). Nous utilisons le taux "done-done" comme point de discussion pendant la rétrospective. Si nous avons déplacé l'histoire, il semblerait que notre taux de réussite soit de 100% à chaque sprint.