Sprint Planning Scrum : rôle et déroulement
Le Sprint Planning est un évènement qui a lieu en tout début de sprint
C'est lors de cet évènement que l'on va définir la composition du sprint.
Comme les autres événements SCRUM, il est limité dans le temps.
On fera en sorte qu'il ne dépasse pas 8 heures.
Mais bien sûr, la plupart du temps, il sera beaucoup plus court et dépendra surtout de la durée du sprint et du nombre de user stories qui seront intégrées dans le sprint.
Lors du Sprint Planning, toute l'équipe participe : le SCRUM Master, le Product Owner, et bien entendu, les développeurs.
On aura parfois besoin, ponctuellement, d'aide extérieure pour avoir un avis sur certains points spécifiques.
Dans ce cas, on pourra inviter un ou des spécialistes pour aider l'équipe dans des choix techniques par exemple...
Ils pourront répondre aux questions que l'équipe se pose, afin de lui permettre de faire des estimations plus réalistes.
Le Sprint planning est l'occasion de répondre à trois questions centrales :
Pourquoi ce sprint est-il important ?
La réponse à cette question sera généralement préparée par le Product Owner, qui est le plus à même d'y répondre, car il connait bien les enjeux et les besoins du client.
Il saura donc expliquer quelle valeur le sprint pourra apporter au client.
Il aura aussi préparé une liste d'user stories qu'il pense pertinent de réaliser durant ce sprint.
Attention, ce n'est qu'une proposition, le Product Owner n'a pas le dernier mot sur les users stories qui seront intégrées au sprint.
La deuxième question à se poser lors d'un sprint planning est ...
Que va-t-on réellement pouvoir faire durant le sprint ?
Là, ce sont les développeurs que l'on va écouter
Les développeurs feront, eux aussi, des propositions en se basant sur plusieurs critères :
La disponibilité de chacun (qui sera présent pendant le sprint, en prenant en compte toutes les absences éventuelles de chacun).
Les performances lors des sprints précédents.
On se servira toujours de l'expérience des sprints précédents pour ne pas répéter les mêmes erreurs, et on arrivera à sentir la vitesse générale de l'équipe pour déterminer la faisabilité de telle ou telle user story dans le cadre du sprint
La bonne connaissance de la Definition of Done, qui est l'ensemble précis des conditions à remplir pour considérer une user story comme terminée.
En fonction de tous ces critères, la liste finale des user stories à intégrer dans le sprint sera définie. C'est le sprint Backlog.
Attention, ici ce sont bien les développeurs qui ont le dernier mot (même si bien sûr, tout doit être discuté et négocié avec le reste de l'équipe).
Le Product Owner, même s'il est arrivé avec une proposition, n'a pas le dernier mot !
D'une manière générale, les Product Owner ont souvent la fâcheuse tendance à être trop optimiste sur la capacité de l'équipe.
Ce sont les développeurs, qui ont la meilleure estimation de leur capacité de travail et donc ont le dernier mot.
La troisième et dernière question à se poser lors d'un sprint planning est ...
Comment les user stories seront-elles réalisées ?
Ici, l'idée est de prendre chaque user story et de définir pour chacune, un plan d'action précis.
Chaque user story aura ainsi sa liste de tâches précises et estimées
En effet, pour chaque tâche, on essaiera de déterminer combien d'heures de travail sont nécessaires.
Cette estimation précise n'est pas indispensable, mais permet une meilleure gestion générale du sprint.