La Product Backlog Refinement est une pratique presque devenue indispensable pour les agilistes. Certains l’appellent encore Grooming (terme à ne plus utiliser). Elle a le rôle comme son nom l’indique d’affiner le contenu du Product Backlog.
Le product backlog refinement est une pratique officielle présentée par le scrum guide dans la partie « product backlog ». Elle n’est pas présentée comme une cérémonie mais comme une pratique !
Nous avions traité le sujet de la backlog refinement en vidéo :
Product Backlog Refinement – les bases
Cette pratique de la Product Backlog Refinement est très en vogue dans le Scrum de nouvelle génération ; elle se transforme en général sous forme de cérémonie. Cependant, cela n’est en aucun cas une obligation et peut se présenter sous d’autres formes.
Qui au product backlog refinement ?
L’ensemble de l’équipe doit participer à la product backlog refinement sans exception :
- le product owner
- l’équipe de développement :
- développeurs
- UX, UI
- Business Analyst
- Testeur
- …
- le scrum master
Les objectifs de cette pratique
Voici un tableau qui vous indique ce qui est nécessaire pour lancer un moment de product backlog refinement et les attendus en sortie :
| Input | Output |
| Avoir accès au backlog et ses items | Affinage avancé des items du product backlog |
| Etre dans les conditions pour travailler sereinement en équipe | Estimation des items envisagés pour les prochains sprints |
| La présence de l’ensemble de l’équipe | Ordonnancement amélioré des items |
| Estimation affinée de la valeur des items |
Beaucoup d’équipes ont tendance à oublier de travailler l’ordonnancement des items et les valeurs de ceux-ci.
Quand faire la product backlog refinement ?
Les équipes la réalise en général une fois par semaine à une heure bien précise. Cependant, selon les besoins, le rythme peut être plus important ou moins important. Généralement, la complexité du produit sera souvent la raison principale du choix du rythme de la mise en place de cette pratique.
On recommande souvent que chaque session de celle-ci ne dure pas plus d’une heure ; elle ne peut également durer que dix minutes si le Product Owner n’a pas besoin de plus de temps.
En effet, ce moment d’affinage est très utile au Product Owner car il va lui permettre d’affiner le contenu de son Product Backlog et ainsi lui permettre de bien organiser les futurs Sprint.
Lors de la Product Backlog Refinement, le Product Owner va proposer des user-stories aux développeurs qui respecteront la définition du « Ready » préalablement défini par l’ensemble de l’équipe.
Déroulement classique d’une product backlog refinement
1/ Compréhension de la user-story
Le product owner va présenter une des user-stories qu’il pense avoir bien avancé ; ce ne sera pas nécessairement une user story qu’il considère comme « ready ».
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écisions 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 rapide 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 point d’effort. Les agilistes conseillent souvent de privilégier l’estimation en point d’effort.
Pour cette estimation lors de la Product backlog refinement, il existe des méthodes très réputées comme le Poker Planning ; n’hésitez pas à aller voir mon article sur cette pratique.
Article : Planning Poker : estimer vos user-stories
Quand le ticket est estimé, le Product Owner propose le ticket suivant.
3/ Ordonnancement du product backlog
Quand tout ce travail est réalisé, l’équipe scrum ensemble évaluera les valeurs des items n’ayant pas encore de valeurs ; cependant, elle peut également revoir les anciennes valeurs afin de les mettre à jour.
Avec ce travail, l’ensemble de l’équipe scrum affinera l’ordonnancement des items du backlog avec 2 objectifs :
- délivrer de le plus de valeur le plus tôt possible
- ne pas être contraint par des aspects techniques
Gains de la Product Backlog Refinement ?
Cette pratique 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 points d’effort qu’il est autorisé à mettre au sein du Sprint qui démarre (chiffre donné par le Scrum Master grâce à ses calculs magiques). Bien que l’équipe de développement sera seule à décider de ce qu’elle réalisera au final (selon les objectif du PO), ce travail en amont mâchera grandement ce travail.
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
- préparer le Sprint Backlog en live (pas toujours simple).
Conclusion Product Backlog Refinement
Il est fortement conseillé de faire la Product Backlog Refinement dans vos processus Scrum ; cette pratique a d’ailleurs été intégrée au scrum guide pour la rendre 100% officielle. Pour ceux qui sont en #NoEstimate, la partie estimation ne sera plus nécessaire ; cependant, je vous conseille de continuer à faire la partie affinage . Cette cérémonie apporte de nombreux gains non négligeables pour le bon déroulement de vos Sprint.
Voici pour finir une vidéo qui vous permettra de comprendre les erreurs à ne surtout pas commettre pour votre product backlog refinement :
14 Rétroliens / Pings