Sprint Planning
Chaque Sprint démarre avec un Sprint Planning lors duquel l'équipe doit définir :
what : l'objectif du Sprint ou Spring Goal,
how : puis comment atteindre cet objectif.
Le Spring Planning peut être divisé en deux parties : Sprint Planning 1 et 2.
La durée maximum du Sprint Planning est de 2h pour un Sprint d'une semaine.
What : Sprint Planning 1 et définition du Sprint Goal
La Scrum Team se réunit en entier (Product Owner, Development Team et Scrum Master) pour définir le Sprint Goal.
Le Product Owner décrit les User Stories qu'il souhaiterait assigner au Sprint.
La Development Team peut interroger le Product Owner pour mieux comprendre le besoin.
Si une User Story est de taille importante, il s'agit alors d'une Epic et la Scrum Team peut alors décider de la décomposer en User Stories plus fines.
La Development Team évalue et sélectionne à elle seule les User Stories qu'elle pense être capable de finir d'ici la fin du Sprint.
Pour optimiser le Sprint Planning en respectant le Timeboxing, pensez à dérouler ces étapes story par story. Ainsi, en cas de "timeout", l'équipe pourra commencer à travailler sur les premières stories. Si l'équipe accomplit sa mission avant la fin de l'itération, on pourra alors planifier un Backlog Refinement pour ajouter de nouvelles stories à l'itération.
Décomposition des Epics
Durant le Sprint Planning, les Epics seront décomposées en User Stories plus fines.
How : Sprint Planning 2
Suite au Sprint Planning 1, la Scrum Team peut libérer le Product Owner.
La Development Team réfléchit et présente la conception / architecture / design de chaque User Story. Cela peut se faire avec toute l'équipe ou par paire afin de paralléliser la réflexion si cela est vraiment nécessaire. Dans ce cas, la paire doit présenter le résultat de sa réflexion au reste de l'équipe.
Chaque User Story est ensuite décomposée en tâches techniques.
Les membres de la Development Team doivent ensuite se répartir naturellement ces tâches.
Personne (ni le Product Owner, ni le Scrum Master, ni le Lead Super Hero Team Scrum Manager) n'assigne les tâches aux membres de la Development Team.
L' effort nécessaire pour chacune des stories peut être estimé en heures mais il est préférable d'utiliser des points.
Estimation de l'Effort
L'effort nécessaire pour réaliser chaque User Story est évalué avec un nombre de points suivant généralement une suite de Fibonacci (1, 2, 3, 5, 8 du plus simple au plus complexe). En pratique, les valeurs 1, 2 et 3 suffisent et encouragent un découpage plus fin.
Planning Poker
Pour encourager tous les membres de la Development Team à participer à l'estimation de l'effort associé aux User Stories, l'équipe peut utiliser un jeu de cartes grâce auquel chacun réfléchit à son estimation puis tout le monde dévoile sa carte simultanément.
Répartition des Tâches
De nombreuses équipes ont le réflexe d'associer chaque tâche à l'expert du sujet.
Bien que cette approche puisse paraître optimale, cela :
décourage le partage de connaissances au sein de l'équipe,
encourage le travail individuel plutôt que l'appropriation du produit par l'équipe,
crée une dépendance forte envers certaines personnes dans l'équipe,
n'encourage pas la remise en question et aboutit souvent à de la complexité artificielle.
Le code le moins maintenable est souvent produits par les experts et non les débutants.
Astuces
Un Sprint Goal convergeant
Définissez un Sprint Goal avec des User Stories fortement liées techniquement et/ou fonctionnellement. Avec des sujets techniques ou fonctionnels liés, proches ou similaires les membres de la Development Team s'intéresseront naturellement aux autres lors du Stand-Up Meeting mais également tout au long du Sprint.
Last updated