Planification de Sprint basée sur la vélocité
Il existe deux approches fondamentales pour planifier un Sprint :
-
Le Sprint Planning orienté vélocité (en tenant compte de la charge de travail moyenne d'une équipe), et
-
Le Sprint Planning orienté engagement (en tenant compte de ce qu'une équipe pense pouvoir accomplir pendant un Sprint).
Planification de Sprint basée sur la vélocité
Il s'agit ici du Sprint Planning basé sur la vélocité. La quantité de travail planifiée pour le prochain Sprint devrait correspondre approximativement à celle des Sprints précédents. Cela suppose bien sûr que la taille de l'équipe reste à peu près la même, que des tâches similaires soient accomplies pendant les Sprints, que les Sprints aient une durée à peu près égale, etc. Heureusement, les écarts par rapport à ces conditions sont faciles à identifier. Si, par exemple, un Sprint ne dure que neuf jours au lieu de dix à cause d'un jour férié, l'équipe le sait bien sûr à l'avance.
Les différentes étapes du Sprint Planning orienté vélocité :
Déterminer quelle était la Vélocité moyenne de l'équipe lors des Sprints précédents.
Sélectionner le nombre approprié d'éléments du Product Backlog en fonction de cette Vélocité.
Identifier les différentes tâches des User Stories et réfléchir si cela pourrait représenter la bonne quantité de travail.
Évaluer si ces tâches nécessitent autant de travail que celles des Sprints précédents.
Examinons ces étapes de plus près.
Étape 1 : Déterminer la vélocité moyenne d'une équipe
La première étape du Sprint Planning orienté vélocité consiste à déterminer la vélocité moyenne d'une équipe. Certaines équipes agiles se basent uniquement sur la vélocité de leur dernier Sprint. Beaucoup d'équipes pensent que c'est le meilleur indicateur de ce qui peut être accompli lors du prochain Sprint. Ce n'est bien sûr pas faux. Cependant, il peut être utile de regarder un peu plus loin en arrière (si ces données sont disponibles).
Pour cela, on examine la vélocité des trois à huit derniers Sprints. L'expérience montre que cela permet de prédire assez bien les Sprints futurs. Bien sûr, il ne faut pas exagérer et calculer la moyenne des dix dernières années. Cela ne dirait finalement rien sur la vélocité actuelle d'une équipe. Cependant, si les données des Sprints précédents sont disponibles, il vaut mieux ne pas se limiter au seul dernier Sprint.
Étape 2 : Sélectionner les Product Backlog Items
Sur la base de la vélocité moyenne qui vient d'être déterminée, les membres de l'équipe peuvent alors sélectionner les items pour le prochain Sprint. Ensemble, ceux-ci devraient correspondre – au moins approximativement – à la vélocité moyenne.
À ce stade, le Sprint Planning orienté vélocité est en principe terminé et peut ainsi être accompli en quelques secondes seulement – dès que l'équipe a sélectionné les Product Backlog Items en fonction de sa vélocité moyenne, c'est fait.
Étape 3 : Identifier les tâches (optionnel)
Souvent, ce court laps de temps ne suffit pas vraiment pour un Sprint Planning. C'est pourquoi les équipes peuvent ajouter une troisième étape à leur planification, où les tâches à exécuter sont identifiées.
Pour cela, les membres de l'équipe discutent de chaque Product Backlog Item sélectionné pour le Sprint. Ils essaient de déterminer quelles étapes de travail sont nécessaires pour terminer les items. Bien sûr, on ne peut pas penser à tout, mais il faut s'efforcer de prendre en compte autant que possible.
Ensuite, l'équipe réfléchit à savoir si les items sélectionnés et les tâches correspondantes rempliront le Sprint. En conséquence, quelques items peuvent encore être ajoutés ou retirés du Sprint.
Certaines équipes terminent leur Sprint Planning à ce stade, d'autres effectuent encore une dernière étape :
Étape 4 : Estimer les tâches (optionnel)
Certaines équipes vont finalement estimer combien d'heures elles auront probablement besoin pour les tâches sélectionnées. Cela leur permet de voir si elles ont planifié la bonne quantité de travail.
Ce texte provient du blog de Mike Cohn et a été traduit par nos soins.
