Un titre qui peut vous sembler exagéré… et pourtant, le Backlog Refinement, ce RDV en cours de sprint est tout simplement crucial pour l’Equipe qui se veut Agile !
Mon message est clair :
Sans Backlog Refinement, vous n’atteindrez pas cette agilité bien huilée que vous recherchez et ces résultats que vous attendez
et simple :
Ceux qui le négligent, ceux qui l’oublient le paient inévitablement ; ceux qui l’adoptent et le réalisent dans de bonnes conditions en redemandent…
Le Backog Refinement est un workshop qui se déroule une à deux fois par sprint, souvent à mi-sprint. Comme son nom l’indique, ce workshop est centré sur le Backlog de produit (c’est à dire la « liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit »). Alors affinage, nettoyage, entretien, maintenance, ou en anglais « grooming », les mots varient mais j’avoue avoir une très nette préférence pour le terme Refinement, popularisé par Craig Larman.
Définitivement collaboratif, le Backlog Refinement doit impliquer tout le monde, du Product Owner (soutenu ou pas par un expert UX ou un Business Analyst), au ScrumMaster en passant par TOUS LES MEMBRES DE l’EQUIPE. Durant mes formations et mon coaching, je présente le Backlog refinement comme un must, le 5 eme RDV incontournable, qui vient s’ajouter aux 4 cérémoniaux Scrum décrits par Sutherland et Schwaber, inventeurs de la méthode Agile la plus populaire… des auteurs qui persistent à limiter la visibilité de cette activité essentielle de préparation tout en reconnaissant paradoxalement son existence!
« Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team. » Scrum Guide July 2011 p13
Et je persiste à penser que « légitimer » son existence en tant que cérémonial Scrum ferait gagner du temps et de l’énergie à pas mal d’Equipes, car même si le format et la durée peuvent varier (3 à 4 heures à mi sprint en une fois ou plus courts en deux temps une fois par semaine), les objectifs, l’agenda, éléments d’entrée / sortie sont clairs, pour une valeur évidente.
Vous l’aurez compris, le Backlog Refinement est un RDV avant tout collectif qui dans les contextes webs et digitaux devient un moment d’expression et de facilitation privilégié pour les experts UX où il s’agira en priorité de décortiquer, d’explorer, de modéliser collectivement le contenu potentiel du sprint qui va démarrer quelques jours plus tard.
Ni trop tôt, ni trop tard dans le Sprint…
Tenir ce Refinement à mi-sprint permet au spécialiste UX, au product Owner ou même à l’équipe de de disposer de suffisamment de temps pour pouvoir le cas échéant peaufiner son besoin, faire un travail de spécifications supplémentaire, explorer une problématique technique ou confirmer des hypothèses auprès des utilisateurs finaux.
Le début-milieu de la seconde semaine sur un sprint de 3 semaine ou la fin de la première semaine pour un sprint de 2 semaines sont des moments propices pour organiser le Backlog Refinement. Le faire le dernier jour du sprint ne présente donc que peu d’intérêt.
Ce workshop peut à son tour donner lieu à des mini workshops spécifications côté Product Owner et/ou Equipe.
Focus sur le sprint n+1… mais pas seulement
J’attends que les équipes se focalisent sur le sprint qui arrive et qu’elles soient en mesure de répondre à cette question :
« Serons-nous Prêts à développer les user stories se trouvant en haut de la pile, ces user stories que nous sommes susceptibles d’embarquer au Sprint suivant ? ».
Ce questionnement implique une activité de modélisation ainsi qu’un travail portant à la fois sur les conditions de satisfaction et sur des exemples (lien avec l’approche ATDD) illustrant les fonctionnalités à développer. Il implique aussi le découpage de certaines users stories trop grosses être développées dans un sprint.
Néanmoins, le focus sur la préparation du sprint suivant n’est pas le seul objectif du Refinement. C’est aussi le moment idéal pour discuter des changements sur le backlog (rappelez-vous mon backlog est DEEP, évolutif, des items peuvent disparaitre, d’autres peuvent émerger, les priorités changent inévitablement.)
Il est aussi souhaitable d’anticiper les risques ou impacts de certains éléments prévus à moyen terme dans les sprints n+2, n+3… besoins de spécialistes, impact techniques, ergonomiques, en terme d’activités de déploiement, de tests ou de support…
Le Backlog refinement: que des bénéfices si on joue le jeu!
Ce workshop collaboratif:
- Donne du contexte et des élements de conversation aux User Stories, pourquoi pas en se basant sur la checklist User Story pour s’assurer qu’on n’oublie rien
- Assure une certaine fluidité et de la sérénité dans le déroulement des sprints
- Illustre et précise les exemples et conditions de satisfaction, qui seront confirmées au moment du Sprint Planning
- Offre un pur moment d’intense collaboration: interactif, visuel, concret et source de feedback…
Bref, le Backlog Refinement, adoptez le sans modération !
