Backlog refinement : la réunion Scrum pour un sprint plus efficace

Non, le backlog refinement n’est pas une énième réunion peu utile imposée par le cadre Scrum… bien au contraire.

Elle a beau ne pas figurer officiellement dans la liste des cérémonies dans le guide Scrum, elle s’impose de plus en plus comme une réunion importante dans les équipes agiles, pour aborder plus sereinement la planification et le déroulement du sprint à venir.

En quoi consiste le backlog refinement et comment se déroule-t-il ? Nous vous livrons également quelques conseils pour un backlog refinement efficace.

Pour bien comprendre le backlog refinement, il faut d’abord être au clair sur la notion de backlog.

Le backlog est une liste de demandes métier concernant un produit ou un projet, traduite sous forme de User stories qui décrivent précisément le besoin utilisateur. Il est constitué et géré par le Product Owner, et toute la team le consulte lors de la planification de sprint afin de sélectionner les stories et fonctionnalités qu’elle s’engage à développer lors du Sprint.

Le backlog refinement, ou backlog grooming, est l’action d’affiner le backlog lors d’une réunion dédiée, en cours de Sprint.

Concrètement, affiner le backlog consiste à :

• clarifier la compréhension des user stories,
• estimer (ou réestimer) l’effort de réalisation,
• déterminer la valeur fonctionnelle de chaque US pour faciliter le travail de priorisation,
• retirer des US (si besoin),
• ajouter des US (si besoin).

🇫🇷 La traduction de backlog refinement en français est l’affinage du backlog.

Quelle est la différence entre le backlog refinement meeting et le sprint planning (planification de sprint) ?

Le sprint planning se déroule le premier jour du sprint, et vise à définir l’objectif du sprint ainsi qu’à sélectionner les User stories que l’équipe s’engage à livrer à la fin. Elle peut durer environ 2 h par semaine de sprint.

Le backlog refinement s’impose comme une réunion intermédiaire et complémentaire à la planification de sprint. Il peut y en avoir plusieurs durant le sprint, et elles ont pour but de préparer le terrain pour le sprint planning, qui devrait être plus efficace.

Qui doit participer à cette réunion ? Tous les membres de l’équipe Scrum doivent y participer :

• la·le Product Owner,
• la·le Scrum Master,
• l’équipe de développement,
• toute autre personne pouvant apporter de l’aide.

👉 La·le Product Owner est chargé de la préparation, de l’organisation et de l’animation du backlog refinement meeting.

Avoir recours régulièrement au backlog refinement présente de nombreux avantages :

• ce travail préparatoire apporte de la sérénité dans la planification et le déroulement du prochain sprint,
• affine la compréhension du besoin,
• prépare l’estimation des User Stories,
• permet de faire un point à mi-parcours,
• peut raccourcir la durée du sprint meeting planning.

Cela dépend des équipes, mais on compte au minimum un backlog refinement meeting d’une heure par sprint.

Dans une logique d’agilité permanente, il est cependant conseillé d’en réaliser plusieurs, quitte à en raccourcir la durée. Cela permet à la ou au Product·Owner d’anticiper et d’avoir le temps de retravailler ses US avant la fin du sprint.

Pour rappel, c’est la·le Product Owner qui est chargé·e de traduire une demande ou un besoin utilisateur en User Story, de manière aussi détaillée et claire que possible.

Elle·il va donc présenter au reste de l’équipe les US qu’elle·il a terminées, ou du moins celles qui sont déjà bien avancées.

L’objectif est de s’assurer de la parfaite compréhension du besoin par les membres de l’équipe de développement, qui pourront poser des questions et échanger autour de ces US. La·le Product Owner pourra alors les modifier ou les enrichir suite aux questions et discussions qui ont eu lieu.

L’équipe peut alors valider la User Story et pourra ainsi passer à son estimation.

👉 S’il s’avère que l’équipe développement ne comprend pas la demande, la·le Product Owner devra prendre du temps pour retravailler et clarifier ses US pour les présenter à nouveau lors de la prochaine session.

La suite logique de la validation des US, est leur estimation par les développeurs.

Chaque équipe dispose de ses propres méthodes et outils pour les estimer, mais dans la pratique, on estime plutôt une US en points d’effort de réalisation plutôt qu’en temps.

Parmi les méthodes les plus couramment utilisées, on note :

• le planning poker,
• la taille de t-shirt,
• le bucket system.

À vous de voir celle qui convient le mieux à votre équipe et à vos projets. S’il s’avère qu’une User story devient compliquée à estimer, mieux vaut la subdiviser en différentes US plus petites pour y voir plus clair.

💡 Bon à savoir : on estime (ou réestime) les User Stories du sprint à venir, ou éventuellement celui d’après, mais on évite d’estimer plus loin.

Connaître l’estimation d’une User Story va permettre à l’équipe de commencer son travail de priorisation.

En revanche, d’autres critères de priorisation peuvent entrer en compte, notamment la valeur fonctionnelle qui est essentielle. C’est pourquoi il est ingénieux de déterminer des niveaux de priorité en fonction du rapport valeur/effort de réalisation :

• priorité 1 (P1) : forte valeur métier et facile à développer,
• priorité 2 (P2) : forte valeur métier et difficile à développer,
• priorité 3 (P3) : faible valeur métier et facile à développer,
• priorité 4 (P4) : faible valeur métier et difficile à développer.

L’équipe attribue donc des ordres de priorité aux US, en gardant bien en tête que l’objectif principal est de délivrer un maximum de valeur le plus rapidement possible.

💡 Bon à savoir : la priorisation peut se faire sur l’ensemble du backlog même si les US ne sont pas toutes complètes car nous sommes sur une vision plus macro.

• Conseil n° 1 : en tant que Product Owner, préparez minutieusement la présentation des US en détaillant à l’équipe votre réflexion, ce que vous pensez qu’elle peut apporter, etc. Plus vous serez enthousiaste et clair·e, plus vous aurez de chance que l’équipe adhère à votre vision produit et valide les US.

• Conseil n° 2 : accueillez les questions, remarques, et retours négatifs. Vous y trouverez forcément quelque chose de constructif qui viendra enrichir votre réflexion et donc vos US.

• Conseil n° 3 : n’attendez pas le dernier moment et d’avoir terminé toutes vos US pour réaliser le backlog refinement. Il vaut mieux présenter régulièrement, lors de backlog refinement rapides, les stories terminées afin d’anticiper s’il y a besoin de les travailler, sous peine de mettre en péril le prochain sprint. Évitez l’effet tunnel !

Et vous ? Avez-vous des conseils à donner à un·e Product Owner qui se lance dans l’aventure du Backlog refinement ?