Organiser une réunion de planification de sprint

De Ensiwiki
Aller à : navigation, rechercher

En début de sprint « Scrum », on planifie le contenu du sprint à venir.

Objectifs de la réunion

En entrée :

  • Une liste de user-stories (backlog), préparée et si possible ordonnée par priorité par le product owner (pour un projet scolaire, le product owner peut être l'enseignant qui encadre le projet).

En fin de réunion :

  • Une liste des user-stories sélectionnées pour ce sprint, avec une estimation en « story points » pour chacune. Le « story point » est une unité de quantité de travail arbitraire, une story à 5 points sera a priori plus longue à réaliser qu'une story à 3 points. Cette liste correspond à un engagement mutuel entre l'équipe et le product owner.
  • Si elle n'a pas été fixée avant, une définition de « fini » (on n'a pas de notion de « à moitié fini » : quelque chose est fini, ou pas fini).

L'équipe peut travailler sur le découpage des stories en tâches techniques (mais les tâches techniques sont de la responsabilité de l'équipe, et non du product owner).

Conseils et outils

Pour l'évaluation

  • Planning poker (demander à Matthieu Moy pour avoir un jeu de cartes)
  • Résultats des sprints précédents pour étalonner la valeur d'un « story point ».
  • Attention à ne pas sous-estimer le travail, et à prendre en compte la définition de « fini » dans l'évaluation. Une tâche d'apparence triviale peut prendre beaucoup de temps si la définition de « fini » inclue la documentation, les tests, l'acceptation par les utilisateurs, ... Une sous-estimation mène à un surengagement pendant la planification de sprint, et donc à des problèmes en fin de sprint.

Pour établir la liste des stories

La liste des N stories les plus prioritaires ne donne pas forcément une quantité de travail raisonnable pour un sprint. Il arrive souvent qu'une story soit trop grosse pour tenir dans le sprint, mais que le backlog soit trop petit si on ne l'inclue pas. Parmi les variables d'ajustement :

  • Modifier les priorités. Par exemple, le product owner peut penser qu'une tâche est facile et la considérer comme prioritaire, mais décider de la remettre à plus tard si l'équipe la considère difficile.
  • Modifier la portée d'une story. Par exemple, on peut demander une preuve de concept au lieu d'une version déployable en production pour réduire le nombre de story points.
  • Découper les stories (« on fait une partie pendant ce sprint, et on garde une autre partie pour le sprint suivant »). Même découpées, les nouvelles stories doivent garder un sens en valeur client. Il ne s'agit pas de découper en sous-tâches techniques. Même si une « grosse » story peut tenir dans le sprint, c'est souvent intéressant de la couper en plus petites stories pour mieux pouvoir répartir le travail en cours de sprint, et limiter les risques en cas d'échec.

Autres sources d'information