Avant propos
Il arrive parfois que des US arrivent en sprint planning sans avoir été étudiées au préalable. Dans le meilleur des cas, ces US sont assez simples à réaliser et les développeurs ne prennent pas trop de temps à les prendre en charge. Cependant, dans certains cas, il arrive que les US en question soient plus robustes et ne soient pas affinées au préalable. Elles peuvent faire perdre un temps précieux au développeur et peuvent engendrer du retard sur la prise en charge des autres US.
C’est à partir de là qu’entrent en jeu les sessions de backlog refinement.
Mais à quoi sert le backlog refinement ?
En premier lieu, le backlog refinement intervient en amont du sprint planning. Il sert à affiner les US prioritaires du backlog. Une US bien affinée est une US bien comprise par les devs, puis si elle est bien comprise, elle peut alors être correctement estimée.
À qui s’adresse-t-il ?
La scrum team : Devs (tous ou une partie), PO (obligatoire) et scrum master (facultatif).
Quand doit servir le backlog refinement ?
Il est important de trouver le juste milieu entre affiner et développer. En effet, trop de backlog refinement peut empêcher les développeurs de développer et les PO de recueillir le besoin. Par contre, pas assez de backlog refinement peut mettre en péril le sprint à venir.
Il existe deux écoles pour savoir quand faire ce point :
- Soit placer un créneau d’une heure de backlog refinement chaque semaine de manière récurrente : Ceci convient généralement bien aux équipes qui ont du mal à dégager du temps de manière spontanée dans leurs semaines. Le créneau est alors bloqué et personne ne vient leur positionner de réunion dessus.
- Soit travailler au fil de l’eau : Le PO gère ses écritures d’US, et une fois qu’une US ou un groupe d’US a fini d’être rédigé, il fait appel aux développeurs. Cela nécessite d’avoir des développeurs flexibles sur leur planning. Le PO peut par exemple faire cette demande pendant le daily et un (ou plusieurs) développeur(s) peut/peuvent également se porter volontaire(s) pour faire l’affinage dans la journée avec le PO.
Le choix de l’une ou l’autre de ces méthodes dépend tout simplement de l’équipe. Il est aussi important de garder à l’esprit que ce n’est pas grave de tester une méthode, puis de passer à la seconde si vous vous rendez compte qu’elle n’est pas adaptée.
Vous pouvez également trouver votre propre méthode en fonction des retours de votre équipe.
Concrètement ça donne quoi ?
Une US ready au sens de votre Definition of Ready.
Comment ?
Il est très important que le PO prenne la main sur cette réunion. En effet, le PO est le garant du produit, il/elle est le/la mieux placé(e) pour présenter l’expression du besoin.
Donc le PO exprime le besoin du métier.
Attention : “exprimer le besoin du métier” ne signifie pas “donner une solution toute prête”.
Voici un exemple :
- Réelle expression de besoin : En tant qu’agent, quand je me rends sur une opportunité fermée, j’ai besoin de pouvoir visualiser en un coup d’œil la date de clôture de l’opportunité.
- Solution déguisée en expression de besoin : En tant qu’agent, quand je me rends sur une opportunité fermée, j’ai besoin de voir un bandeau rouge sur lequel figure la date de clôture de l’opportunité.
Quelle est la différence ?
Dans le premier cas : On exprime ce dont on a besoin sans biaiser le développeur avec une proposition de solution technique.
Dans le second cas : On impose la solution technique au développeur et on biaise donc le développeur.
En résumé dans le premier cas, le développeur peut proposer une solution standard. Par exemple mettre plus en évidence le champ “close date” via la compact layout de l’opportunité par exemple. Au contraire dans le second cas on lui impose une solution custom.
Une fois l’expression de besoin présentée par le PO, les développeurs peuvent affiner l’US, en réfléchissant à une solution technique et en faisant plusieurs propositions au PO. Il arrive que les solutions demandent à être réfléchies au préalable. À ce moment-là, les US concernées sont possiblement affinées après étude de la part des développeurs. Une fois l’US affinée, elle peut être chiffrées et sera alors prête à être embarquée lors du prochain sprint planning.
Sources
https://blog.myagilepartner.fr/index.php/2017/01/17/la-product-backlog-refinement/https://www.youtube.com/watch?v=AqGcUSMGsvM
Vous ne l’avait pas encore lu ? Le deuxième article de cette série parle du Daily team meeeting : Qu’est-ce que l’agilité ? #2 – Le daily team meeting
