Le backlog grooming ou Product Backlog Refinement

http://scrumtrainingseries.com/
Comme vous le savez, une équipe Agile est composée de différents rôles. Le Scrum Master est plus proche de l’équipe de développement et fait tout pour lever les obstacles, l’équipe de développement développe l’application et la teste. Enfin le Product Owner (P.O) tient à jour le Product Backlog afin de pouvoir alimenter l’équipe en stories à développer.
Pour pouvoir proposer de nouvelles stories à l’équipe, le Product Owner doit mettre à jour constamment le Product Backlog. Cependant, il arrive parfois que cette mise à jour du backlog prenne du retard pour diverses raisons :P.O trop occupé par d’autres équipes, d’autres projets, congés, entretiens avec les métiers sur les fonctionnalités, etc…
Il n’est donc pas rare d’arriver en fin de sprint avec un backlog qui n’est pas suffisamment priorisé, ou des Users stories ne sont pas assez claires pour l’équipe ou dont le nombre de users stories n’est pas suffisant pour démarrer un nouveau sprint.

Alors que faire pour pallier à ce problème ?

Différentes méthodes existent telles que l’accompagnement/coaching de Product Owner, la mise en place d’un Product Owner Proxy ou bien encore la mise en place d’un Backlog grooming!
En-effet, une à plusieurs sessions de travail permettant de faire le point en milieu de sprint et/ou en fin de sprint avec le P.O, sont réalisées, afin de vérifier les priorités et adapter le plan de release. Ces réunions de travail entre le P.O, le Scrum Master et même l’équipe de développement permettent de prévoir du temps dans l’agenda chargé du P.O dans cette tâche essentielle à toute réussite d’un projet Agile.
Dans notre cas, nous avons opté pour une réunion en fin de sprint, qui permet de faire le point et de vérifier qu’il ne manque rien au démarrage du prochain sprint quelques jours après.

Avantages:

  • Permet d’éviter des surprises durant la planification du sprint (planning poker), ou pire, durant le sprint, si l’on ne se rend pas compte avant de l’intégration de certaines stories.
  • C’est une pratique qui met en avant un des principes Agile du Manifeste : Les individus et leurs interactions plus que les processus et les outils.

Les modalités:

  • Une salle de réunion
  • Le product backlog
  • Timeboxing d’une à deux heures grand maximum. Si le Product Owner a tenu à jour en continue le Backlog cela peut aisément prendre moins d’une heure.

Ce qu’il en ressort:

  • Un product backlog mis à jour en fonction des dernières priorités données par le Product Owner lors de cette réunion
  • Un product backlog dont certaines users stories sont revues et éclaircies voir même décomposées en plusieurs stories plus petites par le Product Owner et l’équipe lors de cette réunion
  • Un sprint backlog quasi définitif si les users stories ont déjà été estimées lors de sessions de planning poker passées.
  • Un sprint backlog partiel qui est à valider lors de la prochaine réunion de planification de sprint.
Si vous rencontrez aussi des difficultées à obtenir un product backlog prêt avant le nouveau sprint, n’hésitez pas à tester cette pratique et faites moi en part en commentaire !
Bien que cette réunion ne fasse pas partie des cérémoniaux décrit par la méthode Scrum, ce cérémonial est de plus en plus pratiqué par les équipes Scrum. De plus, la version 2013 du guide Scrum écrite par les créateurs de Scrum (Jeff Sutherland et Ken Schwaber) en parle enfin et le recommande en employant le terme de « Backlog refinement »:
Voici un extrait du guide Scrum officiel relatant la mise en place du backlog refinement:
« Le raffinement du backlog de produit (Product Backlog Refinement) consiste en l’ajout de détails, d’estimations et de l’ordonnancement des éléments du Backlog Produit. Il s’agit d’une activité régulière dans laquelle le Product Owner et l’équipe de développement collaborent pour détailler les éléments du Backlog Produit. Durant le raffinement du Backlog Produit, les éléments sont revisités et révisés. L’équipe Scrum décide comment et quand le raffinement est effectué. Le raffinement n’occupe généralement pas plus de 10% de la capacité de l’équipe de développement. Toutefois, les éléments du Backlog Produit peuvent être modifiés à n’importe quel moment par le Product Owner ou à sa discrétion.« 
Petite mise à jour en 2018:
Pour celles et ceux intéressés par cette pratique, je vous invite à aller lire en détail le dernier guide scrum datant de 2017. Voici la version officielle traduite en Français:
Partager cet article:

Ecrit par André De Sousa

Je suis un coach Agile ayant plus de 10 années d'expérience Agile et 15 d'expérience dans la Tech. J'ai coaché/mentoré/animé plus d'une vingtaine d'équipes faisant du Scrum, XP ou du Kanban depuis mes débuts en agilité ainsi que des organisations en pleine transformation agile. Enfin, avec une "fail startup" à mon actif, j'aide les entrepreneurs qui se lancent pour leur éviter de reproduire mes propres erreurs. Actuellement Coach Agile / Formateur / Scrum Master / Hackathon Organizer /Learning Expedition Organizer chez The Valley.

3 Commentaires

  1. obté ou opté ?

  2. Bonjour Crisalide,

    Merci pour ce retour, j’ai ainsi pu corriger mon erreur ! 😉

Trackbacks

  1. […] l’identification des incertitudes, la décomposition en Users Stories avec un premier Backlog Refinement en gardant l’INVEST en tête, l’estimation en points via un premier planning […]

Partager vos opinions ! Laisser un Commentaire

XHTML TAGS AUTORISES

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Vous avez aimé ? Vous aimerez aussi...