Bonjour !
Dans notre dernière leçon, nous avons décortiqué les indicateurs de suivi agiles comme la vélocité et le burndown chart. Vous avez appris que leur fiabilité dépend directement de la qualité des estimations et de la clarté du Product Backlog. Pour avoir de bonnes estimations, il faut une compréhension partagée du travail à faire. C'est précisément l'objectif de la session que nous abordons aujourd'hui.
Cette leçon est la dernière de notre module sur le pilotage d'un projet Scrum. L'objectif est de vous apprendre à organiser et animer une session d'affinage du Product Backlog avec l'équipe. En tant que futur Tech Lead ou chef de projet technique, cette compétence est au cœur de votre rôle : c'est le moment clé où la vision fonctionnelle du produit rencontre la réalité technique de sa mise en œuvre. Maîtriser cette activité vous permettra de garantir que votre équipe travaille sur les bonnes choses, de la bonne manière, et avec une vision claire.
1. Qu'est-ce que l'affinage du Product Backlog ?
L'affinage du Product Backlog (ou Product Backlog Refinement - PBR) est l'activité qui consiste à ajouter des détails, des estimations et un ordre aux éléments du Product Backlog. L'idée est de s'assurer que les éléments qui seront bientôt développés sont bien compris et prêts à être embarqués dans un Sprint.
Contrairement aux autres "cérémonies" Scrum, le Guide Scrum ne le définit pas comme un événement formel avec une durée fixe, mais plutôt comme une activité continue qui a lieu tout au long du Sprint.
Pour mieux saisir cette nuance et l'objectif de l'affinage, je vous propose de regarder une courte vidéo.
Evolution de Scrum : backlog refinement / grooming
La vidéo "Evolution de Scrum : backlog refinement / grooming" de la chaîne Scrum Life explique clairement ce qu'est l'affinage, pourquoi il est important, et pourquoi il est considéré comme une activité continue plutôt qu'un événement formel.
Regardez le début de la vidéo jusqu'à 01:59. Concentrez-vous sur la définition de l'affinage, son objectif (décomposer et définir les éléments), et l'exemple concret de discussion qui illustre comment l'équipe affine une demande sans parler immédiatement de solution technique.
Le but n'est donc pas de tout planifier en détail, mais de maintenir un backlog sain où les éléments les plus prioritaires sont toujours clairs et prêts pour le développement. On peut visualiser ce processus comme un entonnoir.
Concrètement, un affinage réussi permet :
- d'avoir une compréhension partagée du besoin entre le Product Owner et les développeurs.
- de s'assurer que les User Stories sont prêtes (on utilise souvent l'acronyme DEEP : Detailed appropriately, Estimated, Emergent, Prioritized).
- de rendre les sessions de Sprint Planning beaucoup plus courtes et efficaces, car une grande partie de la discussion a déjà eu lieu.
- d'identifier en amont les dépendances, les risques et les incertitudes.
2. Les activités clés de l'affinage
Affiner le backlog se décompose en plusieurs actions interdépendantes. En tant qu'animateur, vous devrez vous assurer que ces activités se déroulent de manière fluide.
a) Discuter et Clarifier
Le Product Owner présente les User Stories les plus prioritaires. L'équipe de développement pose des questions pour éliminer toute ambiguïté sur le "quoi" et le "pourquoi". Votre rôle de Tech Lead est ici crucial pour poser les questions techniques pertinentes qui permettent de cerner les impacts et les contraintes.
b) Décomposer (ou "Splitter")
Souvent, une User Story ou une fonctionnalité (parfois appelée "Epic") est trop grosse pour être réalisée en un seul Sprint. L'un des objectifs majeurs de l'affinage est de la découper en User Stories plus petites et gérables.
L'image ci-dessous illustre bien cette hiérarchie, d'une idée large à des tâches concrètes.
Ce découpage est un art. En tant que développeur, vous savez qu'il y a plusieurs manières de "trancher" une fonctionnalité. C'est une discussion collaborative où votre expertise technique sera précieuse pour proposer des découpages logiques qui apportent de la valeur à chaque étape.
c) Estimer
Une fois qu'une User Story est suffisamment claire et petite, l'équipe de développement l'estime. Comme nous l'avons vu, cela se fait souvent en points de complexité (et non en jours/hommes). Cette estimation n'est pas un engagement, mais une évaluation de l'effort relatif qui aidera le Product Owner à prioriser.
d) Ordonner
Enfin, sur la base de la valeur métier et des estimations d'effort, le Product Owner (avec l'aide de l'équipe) ordonne les éléments dans le backlog. L'objectif est de maximiser la valeur livrée.
3. Comment organiser et animer une session d'affinage ?
Même si l'affinage est une activité continue, la plupart des équipes organisent des réunions dédiées pour le faire. Voici un guide pratique pour les préparer et les animer.
Backlog refinement : réunion Scrum pour affiner le product ...
L'article "Backlog refinement : réunion Scrum pour affiner le product ..." du site appvizer.fr est un excellent guide pratique. Il détaille qui doit participer, combien de temps y consacrer, et comment se déroule une session typique.
Lisez attentivement les sections suivantes : "Qui sont les participants du backlog refinement ?" pour comprendre les rôles de chacun. "Quelles sont la durée et la fréquence de son exécution ?" pour retenir la règle empirique des 10%. "Quelles sont les étapes préalables au déroulement du backlog refinement ?" pour comprendre l'importance de la préparation. "Déroulement du backlog refinement" pour visualiser les étapes d'une session.
En s'inspirant de cet article et d'autres bonnes pratiques, voici une synthèse pour vous guider.
Le cadre de la session
- Qui ? L'équipe Scrum au complet : Product Owner, Scrum Master et tous les Développeurs. Le PO anime généralement, mais le Scrum Master ou un Tech Lead peut aussi faciliter la session.
- Quand ? La plupart des équipes bloquent 1 à 2 créneaux par Sprint. Une bonne pratique est de ne pas attendre la veille du Sprint Planning !
- Combien de temps ? Le Guide Scrum suggère que l'affinage ne devrait pas prendre plus de 10% de la capacité de l'équipe de développement. Pour un Sprint de 2 semaines, cela représente environ une journée, souvent répartie en plusieurs sessions plus courtes (ex: 2 x 2 heures).
L'agenda type d'une session d'affinage
Le document "Le guide du product owner" propose un mémo très efficace qui résume l'agenda d'une session d'affinage. En voici une version que vous pouvez adapter :
- Introduction (5 min) : Le PO rappelle l'objectif de la session et présente la liste des 2-3 User Stories prioritaires à discuter.
- Présentation de la 1ère User Story (10 min) : Le PO explique le besoin utilisateur, le contexte et les critères d'acceptation.
- Clarification & Discussion (15 min) : C'est le cœur de la session. L'équipe pose des questions. En tant que Tech Lead/facilitateur, votre rôle est de :
- Encourager tout le monde à participer.
- Recentrer la discussion si elle dérive vers des solutions techniques trop détaillées. L'objectif est de comprendre le "quoi", pas encore le "comment".
- Faire émerger les risques, les dépendances et les points bloquants.
- Découpage si nécessaire (10 min) : Si l'équipe juge la story trop grosse ("C'est un 20 points ça !"), vous facilitez un atelier rapide pour la découper en stories plus petites.
- Estimation (5 min) : L'équipe vote (par exemple avec un Planning Poker). Si les estimations divergent fortement, c'est le signal d'une incompréhension. Facilitez la discussion entre ceux qui ont voté le plus bas et le plus haut pour aligner la compréhension.
- Répéter pour les stories suivantes.
- Conclusion (5 min) : Le PO résume les décisions et s'assure que les stories discutées sont bien mises à jour dans l'outil de gestion de projet.
Testez votre compréhension !
Vous animez une session d'affinage. Pour la User Story "En tant qu'utilisateur, je veux pouvoir payer ma commande avec PayPal", les estimations de l'équipe sont très variées : 3, 5, 8, 13, 20.
Quelles sont vos hypothèses pour expliquer cette divergence ? En tant que facilitateur, que faites-vous ?
Show answer
Hypothèses possibles :
- Incompréhension du périmètre : Certains développeurs pensent juste à ajouter un bouton PayPal, d'autres incluent la gestion des erreurs, les notifications par email, la mise à jour du statut de la commande, et la gestion des remboursements.
- Connaissance inégale de la technologie : Un développeur a déjà intégré PayPal et sait que c'est simple (vote 3 ou 5). Un autre n'a jamais touché à une API de paiement et imagine une complexité énorme (vote 13 ou 20).
- Risques non identifiés : Un développeur senior pense à l'impact sur la sécurité, la comptabilité, ou la conformité RGPD, ce que les autres n'ont pas considéré.
Actions en tant que facilitateur :
- Ne pas faire la moyenne. Ne dites surtout pas "Ok, on coupe la poire en deux, on met 8".
- Faire parler les extrêmes. Demandez au développeur qui a voté "3" d'expliquer son raisonnement. Ensuite, demandez à celui qui a voté "20" d'expliquer pourquoi il voit autant de complexité.
- Clarifier le périmètre. La discussion va faire émerger les points oubliés. Le PO peut alors clarifier : "Pour cette story, nous ne nous occupons pas des remboursements, ce sera une autre story. En revanche, la gestion des erreurs de base doit être incluse."
- Décider de splitter. Si la story inclut trop de choses, proposez de la découper. Par exemple : une story pour l'intégration du paiement, une autre pour la notification email.
- Re-voter. Une fois la discussion terminée et la story éventuellement redéfinie, lancez un nouveau tour d'estimation. Les votes devraient converger naturellement.
4. Un exemple concret pour finir
Pour vous projeter dans une situation réelle, le guide du Product Owner contient un excellent exemple narratif. Il met en scène "Pat", une Product Owner, qui anime son atelier d'affinage hebdomadaire.
Cette annexe du "Guide du product owner" est une lecture très parlante qui raconte comment se passe une session d'affinage dans la pratique. C'est moins formel qu'un guide, et ça vous aidera à sentir l'ambiance et la dynamique de ce type de réunion.
Lisez l'extrait qui se trouve à la page 87 du PDF. Il commence par "Pat mène un atelier d’affinage tous les mercredis de 11h à 12h." et se termine un peu plus bas. Observez comment la discussion mélange estimation de valeur, estimation de taille (effort), et découpage des User Stories.
Conclusion
L'affinage du Product Backlog est bien plus qu'une simple réunion : c'est le moteur qui alimente le flux de développement de l'équipe Scrum.
Les points clés à retenir :
- Ce n'est pas un événement formel, mais une activité continue qui vise à avoir constamment des éléments "prêts" au sommet du backlog.
- Les activités clés sont : discuter, clarifier, décomposer, estimer et ordonner.
- C'est un effort d'équipe où le dialogue entre le PO et les développeurs est essentiel pour construire une compréhension commune.
- Votre rôle de facilitateur (en tant que Tech Lead, Scrum Master ou PO) est de structurer la session, de vous assurer que les objectifs sont atteints, et de garantir que la discussion est constructive et inclusive.
En maîtrisant l'organisation et l'animation de ces sessions, vous jouerez un rôle central dans la réduction des incertitudes, l'amélioration de la prédictibilité de votre équipe et, au final, dans la livraison d'un produit de plus grande valeur.
Dans notre prochaine leçon, nous allons entamer un nouveau module sur la Gestion des Risques et des Problèmes. Nous commencerons par la base : apprendre à distinguer un risque (un événement incertain futur) d'un problème (un événement avéré). Vous verrez que l'affinage du backlog est en fait l'une des premières et des plus efficaces techniques de gestion des risques d'un projet : chaque question posée, chaque story découpée, est une manière de transformer une incertitude (un risque) en une information connue.