Un Product Owner peut avoir son propre board pour gérer son product backlog afin de simplifier considérablement son organisation. On l’appelle le Product Board. Cet article a pour but de montrer comment réaliser le product board du Product Owner pour qu’il soit le plus efficace possible.
Certains appellent ce product board : le board de maturation ou le board de fertilisation. Vous pouvez sans soucis utiliser le terme qui vous parle le plus.
Création du product 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 des outils très utiles pour tous les membres d’une équipe Scrum même pour le Product Owner.
Analysons les besoins d’un Product Owner assez classiques pour réaliser notre product 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-stories de notre Product Owner ; cela permettra de créer les colonnes 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 analyse va regarder si la user-story a :
- un besoin extérieur (partenaires technologique par exemple),
- des connexions avec d’autres outils
- son besoin est bien identifié…
Elle permettra de bien analyser la demande en détail les clients.
Cette colonne permettra également 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).
Wireframe et validation avec le client
Nous allons ajouter une colonne pour le travail sur le UX (User eXperience) très apprécié dans le monde de l’agilité. Ce travail sera souvent fait part une personne experte dans le domaine mais rien n’interdit le Product Owner de le faire. Cependant, nous savons bien que chacun est expert dans son domaine.
Quand les wireframe seront correct (l’aspect visuel n’étant pas travaillé à ce moment là), l’UX Designer et le Product Owner iront les valider avec les clients voire les parties prenantes.
Test d’acceptance
Le PO écrira ensuite les tests d’acceptance si elles sont obligatoires dans la définition d’une user-story « ready » ; cela permettra de décrire les scénario qui suivent les travaux réalisés par l’UX Designer à l’étape précédente..
Dès que tout est bon, il pourra passer son ticket à la priorisation.
UI
Cette colonne du Product Board est utile pour finaliser la partie UI essentielle pour les équipes qui désirent avoir une estimation relativement juste. En général, cette partie est gérée par un UI Designer.
A estimer
Quand le Product Owner a besoin de faire estimer une demande à l’équipe de développement il va mettre les user-stories dans cette colonne. Elles seront en attente de la prochaine Product Backlog Refinement.
Planification
Cette colonne finale du Product Backlog permet au Product Owner de préparer les futurs Sprint de l’équipe. Les user-stories sortent de cette colonne (et du board) en début du Sprint ; elles vont directement sur le board de l’équipe de développement.
Résultat du product board
Voici le résultat du product board que nous venons de décrire colonne après colonne :
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. Cependant il est possible et conseillé de l’adapter à votre contexte.
N’oubliez pas par contre de ne pas trop multiplier vos colonnes ; il ne faut mettre que les étapes essentielles du cycle de vie de vos user-story dans le product backlog.
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