Quand un Sprint est-il terminé ?

Il arrive assez fréquemment qu'une équipe se retrouve avec des travaux inachevés à la fin d'un sprint agile ou d'une itération. Idéalement, une équipe terminerait toujours chaque élément du Sprint Backlog pendant le sprint. Cependant, pour diverses raisons, ce n'est pas toujours le cas. Cela nous amène à quelques questions que je vais aborder ci-dessous :

• Que doit-il advenir de chaque élément du Product Backlog ?

• Faut-il le diviser ou le reporter au prochain Sprint ? L'équipe devrait-elle comptabiliser les points des parties terminées de la Story dans sa Velocity ?

L'item est-il encore pertinent ?

Lorsqu'un Product Backlog Item n'a pas été terminé à la fin d'un Sprint, il devrait normalement être replacé dans le Product Backlog. Le travail n'est jamais automatiquement reporté d'un Sprint à l'autre.

Je suis peut-être un peu trop pointilleux sur ce sujet, mais ce qui m'importe, c'est que chaque Sprint commence par une décision consciente du Product Owner sur ce sur quoi l'équipe doit travailler. Bien sûr, il est très probable que le Product Owner souhaite que l'équipe termine le travail inachevé du Sprint précédent dans le nouveau Sprint. Cependant, cela devrait toujours être une décision consciente du Product Owner.

(Juste une remarque : je ne dis pas que tu dois te compliquer la vie si tu utilises un outil qui rendrait cela trop complexe. Je dis simplement que le travail n'est pas automatiquement reporté au Sprint suivant. Le Product Owner devrait toujours décider si le travail est encore pertinent.)

Diviser ou reporter au prochain sprint ?

Lorsqu'un Product Backlog n'a pas pu être entièrement terminé, les membres de l'équipe se demandent souvent s'ils doivent laisser le Product Backlog Item tel quel (même si une partie de la fonctionnalité est déjà prête) ou s'ils doivent le réécrire pour ne décrire que la partie manquante.

Exemple : Prenons l'exemple d'une équipe qui travaille sur une fonction classique d'aperçu avant impression pour une application de bureau. Si l'équipe a tout terminé sauf la possibilité de feuilleter les pages en arrière, les membres peuvent soit reprendre la User Story originale dans le prochain Sprint, soit écrire une Story plus petite en remplacement : « En tant qu'utilisateur, je veux pouvoir revenir en arrière lorsque l'aperçu avant impression est affiché. »

Si la Story est terminée lors du Sprint suivant, je suggérerais de la laisser simplement telle quelle et de ne pas la réécrire. Tout le monde connaît la Story telle qu'elle a été rédigée jusqu'à présent. Donc, si le Product Owner la considère toujours comme importante, elle passe dans le prochain Sprint sans modification.

Cependant, si le travail restant est reporté à un Sprint ultérieur, une nouvelle Story devrait être rédigée, décrivant uniquement la partie inachevée de la fonctionnalité.

À retenir : Si le travail est terminé lors du Sprint suivant, la Story n'est pas réécrite.

Est-ce que l'équipe obtient des points pour la vélocité ?

J'adopte volontiers un point de vue plutôt conservateur en ce qui concerne la Velocity. Cela signifie qu'une équipe ne devrait obtenir des points que pour le travail qui est réellement terminé. Concrètement :

1. Si un élément du Product Backlog non terminé est repris dans le sprint suivant et y est finalisé, l'équipe ne devrait pas recevoir de points pour celui-ci dans le sprint initial. À la place, l'équipe reçoit tous les points pour la story dans le sprint où le travail est réellement terminé. Comme je recommande de toute façon de travailler avec une vélocité moyenne, cela s'équilibre et il n'y a pas de risque que la vélocité soit surévaluée.

2. C'est différent cependant si l'équipe décide de diviser la story et de remettre le travail restant dans le Product Backlog pour y travailler plus tard. Dans ce cas, les points pour le travail accompli sont crédités à l'équipe. Les membres de l'équipe doivent alors estimer du mieux possible combien de points le travail accompli vaut. Même si la story complète n'est pas encore terminée, il est possible que l'équipe reçoive tous les points initiaux de la story, car il se peut que la story était finalement plus importante que prévu. Cela ne devrait pas arriver constamment, mais de temps en temps c'est acceptable.

Conclusion : Toujours chercher la cause

Lorsqu'il reste du travail inachevé à la fin du Sprint, l'équipe devrait toujours prendre le temps lors de la rétrospective de déterminer si la cause aurait pu être évitée. Parfois, c'est simplement de la malchance ou un mauvais timing ; par exemple quand un membre de l'équipe tombe malade ou qu'un problème surgit qu'on ne pouvait pas prévoir au début du Sprint. Cependant, il est toujours judicieux de réfléchir à la cause et à la manière d'éviter cela à l'avenir.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.

User Stories, Epics, Themes

Nous expliquons la différence entre ces éléments.
=>User Stories, Epics, Themes

Développer un produit

De l'idée à la réalisation avec le Product Vision Board.
=>Product Vision Board

Que sont les Story Points ?

Découvre comment améliorer l'estimation de ton équipe.
=>Que sont les Story Points ?