La Product Backlog Refinement

La Product Backlog Refinement également appelée Grooming est une cérémonie presque devenue indispensable pour les agilistes. Elle a le rôle comme son nom l’indique d’affiner le contenu du Product Backlog.

Déroulement de la Product Backlog Refinement

Cette cérémonie très en vogue dans le Scrum de nouvelle génération se fait en général une fois par semaine à une heure bien précise.

On recommande souvent que chaque session de celle-ci ne dure pas plus d’une heure ; elle peut également durer que dix minutes si le Product Owner n’a pas besoin de plus de temps.

En effet, cette réunion est très utile au Product Owner car elle va lui permettre d’affiner le contenu de son Product Backlog et ainsi lui permettre de bien organiser les Sprint.

Lors de cette cérémonie Scrum, le Product Owner va proposer des user-story aux développeurs qui respecteront la définition du “Ready” au préalablement définit par l’ensemble de l’équipe.

1/ Compréhension de la user-story

Les développeurs vont alors tenter de comprendre la user-story et parler ensemble de celle-ci. Ils pourront profiter de ce moment pour demander plus de précision au Product Owner si il subsiste quelques doutes sur la demande. En général, ceci amène le Product Owner à modifier légèrement le contenu de la demande en prenant en compte les remarques des développeurs.

Il y a alors deux issues à cette discussion parfois d’ailleurs très rapides quand le ticket est compris dès le début :

  • Les développeurs valident le ticket qui pourra alors être estimé
  • Les développeurs ne comprennent pas le ticket ce qui imposera au Product Owner de revoir sa copie jusqu’à la prochaine session.

2/ Estimer la demande

Les développeurs vont alors faire une estimation de la demande ensemble en temps ou en complexité (appelé aussi point d’effort). Les agilistes conseillent souvent de privilégier l’estimation en complexité.

Pour cela il existe des méthodes très réputées comme le Poker Planning que nous verrons dans un futur article.

Quand le ticket est estimé, le Product Owner propose le ticket suivant.

Gains de la Product Backlog Refinement ?

Cette cérémonie propose de nombreux avantages pour les équipes Scrum.

Elle permet au Product Owner d’arriver en Sprint Planning Meeting avec un Sprint Backlog déjà préparé selon le nombre de complexités qu’il est autorisé à mettre au sein du Sprint qui démarre (chiffre donné par le Scrum Master grâce à ses calculs magiques).

En conséquence tout ce travail en amont réduit considérablement le temps de la Sprint Planning Meeting qui impose sans cette réunion de faire ce travail d’estimation et de préparer le Sprint Backlog en live (pas toujours simple).

Le fait de pouvoir faire estimer des tickets pas forcément pris en charge de suite permet aussi au Product Owner avec l’aide du Scrum Master de pouvoir créer des roadmap théoriques des projets plutôt justes. Certaines entreprises imposent cette obligation de roadmap.

L’estimation en amont des user story peut permettre également de se faire une meilleure idée de certains projets (et de leur ampleur) et de revoir sa copie si les estimations sont bien au-dessus de ce qui était prévu. Cela permet également de calculer un ROI pour ceux qui utilisent la priorisation par Business value (Prioriser avec les Business Value).

Conclusion

Il est fortement conseillé de faire la Product Backlog Refinement dans vos processus Scrum pour ceux qui ne se sont pas déjà lancé dans le #NoEstimate. Cette cérémonie apporte de nombreux gains non négligeables pour le bon déroulement de vos Sprint.