Le board du Product Owner

Ecrit par << Paquet Judicaël >>

Un Product Owner peut avoir son propre board pour gérer son product backlog afin de simplifier considérablement son organisation. Cet article a pour but de montrer comment réaliser le board du Product Owner pour qu’il soit le plus efficace possible.

Création du board

Le Product Owner n’a pas les mêmes besoins que les équipes de développement. Grâce à l’aide du Scrum Master, il va pouvoir créer un board qui lui est dédié dans la gestion de son Product Backlog.

Oui, les boards et les post’it peuvent être un outil très utile pour tous les membres d’une équipe Scrum même le Product Owner.

Analysons les besoins d’un Product Owner assez classiques pour réaliser notre board de base. Vous pourrez bien évidement adapter ce board du Product Owner au contexte de votre entreprise ; le but de cet article est de vous donner une bonne idée de base d’un outil qui a fait ses preuves.

Nous allons décrire chaque étape du cycle de vie des user-story de notre Product Owner pour les transformer en colonne sur le board du Product Owner.

Etude de faisabilité

Il n’est pas rare qu’un Product Owner (PO) ait le besoin de réaliser une petite étude de faisabilité avant de proposer une user-story aux équipes.

Cette études de faisabilité va regarder si la user-story a un besoin extérieur (partenaires technologique par exemple) et bien analyser la demande en détail des clients.

Le PO en profitera d’ailleurs pour écrire les tests d’acceptance si elles sont obligatoires dans la définition d’une user-story « ready ».

Dès que tout est bon, il pourra passer son ticket à la priorisation.

A prioriser

Cette colonne est utile dans le cas où il y a de très nombreuses user-story qui rentrent dans le Product Backlog voire qu’il y en a plus que de demandes traitées par l’équipe de développement.

Cette colonne permettra de faire le tri des demandes qui seront données aux développeurs et des demandes qui n’aboutiront jamais. Un Product Owner a souvent la lourde tâche de devoir faire des choix sur les user-story à gérer.

Il pourra également demander aux équipes métiers de mettre une Business Value afin de l’aider dans ses choix et ses planifications (article sur la priorisation avec les Business Value).

A estimer

Quand le Product Owner a besoin de faire estimer une demande à l’équipe de développement il va mettre les user-story dans cette colonne en attente de la prochaine Product Backlog Refinement (la Sprint Planning Meeting si l’équipe ne fait pas cette cérémonie).

A compléter

Quand l’équipe de développement rejette une user-story parce qu’elle n’est pas complète, le Product Owner va mettre celle-ci dans cette colonne afin de la traiter rapidement. Il pourra la remettre dans « A estimer » quand il l’aura compléter selon les différentes remarques de l’équipe.

Evaluation C/BV

Si vous utilisez les priorisations avec les Business Value, vous pourrez mettre vos user-story dans cette colonne pour calculer le ROI de celles-ci. C’est une étape très courte qui n’est pas forcément obligatoire.

Plannification

Cette colonne finale du Product Backlog permet au Product Owner de préparer les futurs Sprint de l’équipe. Les user-story sortent de cette colonne (et du board) en début du Sprint pour aller directement sur le board de l’équipe de développement.

Résultat

Voici le résultat du board que nous venons de décrire colonne par colonne :

Board Product Owner
Board Product Owner

Comme je le disais plus haut, le but est de vous donner de bonnes idées sur la création d’un board utile pour le Product Owner de l’équipe mais il est possible et conseillé de l’adapter à votre contexte.

N’oubliez pas par contre de ne pas trop multiplier vos colonnes et de n’y mettre que les étapes essentielles du cycle de vie de vos user-story dans le product backlog.

5 réponses sur “Le board du Product Owner”

  1. Pour ma part, j’utilise aussi le board du po pour permettre aux différents demandeurs de déposer leurs besoins (colonne inbox), indiquer leur maturité au fur et a mesure (non spécifié/cadré, en cours, défini), les sujets écartés (abandonné) pour eviter qu’on repropose 15 fois le même sujet, ce qui permet de creer aussi un bac à sable ouvert à tous les demandeurs en amont des créations de sprint, et donnant aussi aux différents demandeurs (stackholders) une visibilité sur les sujets à venir et ce qui a été retenu sans trop poluer le vrai backlog à destination de l’équipe Scrum

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.