Tout savoir sur la plani­fi­ca­tion de sprint

La plani­fi­ca­tion de sprint est l’une des réunions qui rythment un projet Scrum. Elle est indis­pen­sable au bon dérou­le­ment de chaque itéra­tion et déter­mine en grande partie la réus­site ou l’échec d’un sprint.

Les pré-requis de la plani­fi­ca­tion de sprint

Avant de pouvoir mettre en place la première réunion de plani­fi­ca­tion de sprint, un certain nombre de points doivent être réali­sés au préa­lable. 

1. La durée des sprints doit avoir été déci­dée : Cela déter­mi­nera la durée de la plani­fi­ca­tion de sprint. Géné­ra­le­ment, la réunion de plani­fi­ca­tion ne dépasse pas huit heures et sa durée est ajus­tée en fonc­tion de la longueur des sprints, sur la base de deux heures par semaine de sprint. 
2. Le Product Back­log doit être ordonné par impor­tance. Les éléments dispo­sant des plus hautes prio­ri­tés devront être détaillés. 
3. Il est aussi impé­ra­tif que le Product Owner connaisse suffi­sam­ment le produit et les attentes des utili­sa­teurs afin de pouvoir rensei­gner l’équipe.

Une réunion où tous les parti­ci­pants sont actifs

Lors de la réunion de plani­fi­ca­tion, tous les membres du projet doivent être présents, car tout le monde a un rôle à jouer. Le Scrum­Mas­ter, en tant que maître de céré­mo­nie, animera la rencontre et s’as­su­rera que celle-ci se déroule dans les meilleures condi­tions possibles. Le Product Owner présen­tera les items à plus forte impor­tance ainsi que les diffé­rentes tâches néces­saires à leur réali­sa­tion. Il défi­nira égale­ment de manière claire les critères d’ac­cep­ta­tion de chaque item. L’équipe devra quant à elle déci­der de la quan­tité de travail qu’elle se sent capable de réali­ser sur la durée du sprint et en prendre l’en­ga­ge­ment. Il est à noter égale­ment que le premier sprint est géné­ra­le­ment consa­cré à l’ar­chi­tec­ture et sa faisa­bi­lité.

Dérou­le­ment de la réunion de plani­fi­ca­tion

Dans un premier temps, le Product Owner va contex­tua­li­ser le futur sprint en défi­nis­sant son but et son péri­mètre. L’équipe doit alors sélec­tion­ner l’item qu’elle pense pouvoir réali­ser dans la durée du sprint, parmi ceux ayant le plus grand coef­fi­cient d’im­por­tance sur le Product Back­log. L’équipe réper­to­rie alors les diffé­rentes tâches néces­saires à la réali­sa­tion de l’item sélec­tionné et confirme ou modi­fie la prévi­sion initiale avec le Product Owner. Enfin, ce dernier défi­nit de manière claire les condi­tions d’ac­cep­tion de l’item et les critères de test avec l’équipe. Si les deux parties ne parviennent pas à trou­ver un terrain d’en­tente, l’item est écarté du sprint. 

Les diffé­rentes étapes sont répé­tées avec les items suivants jusqu’à ce que le plan­ning du sprint soit complet. Il est impor­tant de préci­ser qu’un item ne peut être inté­gré au plan­ning d’un sprint que si l’in­té­gra­lité des tâches qu’il néces­site peut être réalisé durant le sprint en ques­tion. À la fin de la réunion, l’équipe s’en­gage sur le plan d’ité­ra­tion, appelé Sprint Back­log et le sprint peut démar­rer.

Pour certains, se passer de cette étape est incon­ce­vable. Pour­tant, le rapport annuel de l’édi­teur Versio­nOne rapporte qu’en 2014, seuls 69 % des équipes agiles y avaient recours. Une autre étude de Rally Soft­ware affirme que les projets ayant béné­fi­cié de cette plani­fi­ca­tion était 3,5 fois plus quali­ta­tifs. Voilà des éléments qui devraient convaincre les derniers scep­tiques quant à l’uti­lité de cette plani­fi­ca­tion.