Une nouvelle réunion Scrum : la revue de backlog

Encore une revue ? Oui mais pour gagner du temps !

Bien souvent, la revue de planification de sprint dure longtemps, trop longtemps, suite à des discussions parce que l'équipe a du mal à voir le périmètre des histoires d'utilisateur proposées par le Product Owner. Pour éviter de dépasser la durée normale de cette réunion, il arrive que l'équipe accepte d'inclure une histoire dans le sprint courant alors qu'elle ne sait pas bien la décomposer en tâches. Cela risque de provoquer des problèmes dans le déroulement du sprint.

Pour éviter cette dérive, je propose d'ajouter une revue, un peu avant la fin du sprint précédent.

Comme cette réunion porte sur le backlog, je suggère de l'appeler la revue de backlog. Elle a pour objectif de :

  • tenir compte de ce été modifié dans le backlog de produit[1]
  • préparer le sprint suivant et faciliter la planification, pour pallier le problème évoqué ci-dessus.

Déroulement

  • Le Product Owner présente les éléments du backlog pas encore estimés et qu'il veut voir estimés par l'équipe
  • L'équipe estime ces éléments
  • Le Product Owner présente les éléments qu'il pense inclure dans le prochain sprint
  • L'équipe se détermine pour chaque élément présenté :
    • soit elle considère que l'élément peut être inclus dans le prochain sprint
    • soit elle considère que la présentation faite par le Product Owner est insuffisante et ne permet pas l'inclusion de l'élément dans le sprint à venir. Dans ce cas, il restera quelques jours au directeur de produit pour compléter la connaissance relative à cette histoire. S'il ne peut pas le faire d'ici au début du sprint, l'élément ne sera pas inclus dans le sprint.

Dans quel cas peut-on s'en passer ?

Si suffisamment d'éléments sont prêts à être inclus dans le prochain sprint, la réunion n'est pas utile.

Durée

Une heure maximum. Cette durée supplémentaire en réunion est largement amortie par la diminution de celle de planification et par le temps gagné sur le travail du sprint.

Quand ?

Il faut tenir cette réunion un peu avant la fin du sprint. Pas trop tard pour laisser un peu de temps au Product Owner s'il lui faut approfondir des éléments. Pas trop tôt pour avoir une idée de ce qui sera effectivement fini à la fin du sprint. Pour des sprints qui durent 3 semaines, je conseille de la tenir 3 jours avant la revue de fin.

Point-clé

Il ne s'agit pas pour l'équipe de tomber dans l'excès qui consiste à demander une spécification détaillée. Il faut rester dans l'esprit des 3C. Une bonne approche est de définir des tests d'acceptation et éventuellement d'utiliser la technique de formalisation des critères d'acceptation.


Notes

[1] les éléments ajoutés notamment, ce qui permettra de savoir combien de points il reste à faire et de remettre à jour le planning de release