Product Owner – rôle

Le Product Owner (PO) – son rôle

Nous avions vu le rôle du Scrum Master dans un précédent article ; voici à présent le rôle du Product Owner qui est souvent bien mieux compris dans le monde de l’entreprise.

Cependant ce rôle comporte quelques subtilités encore assez males comprises dans les équipes scrum. Donc nous allons voir justement ces subtilités au cours de cet article.

Sachez que le Product Owner est souvent appelez PO dans les entreprises ; attention, dans certaines entreprises, le terme PO peut également se traduire par project owner, ce qui est un rôle très différent.

Le Product Owner est un des 3 rôles clés du scrum :

• scrum master
• product owner
• équipe de développement

D’ailleurs, vous pouvez regarder la vidéo de la minute agile sur le PO :

Les responsabilités du product owner

Responsable de la valeur à livrer, pas de ce qui est livré !

Pour commencer, voici la première phrase très importante proposée par le scrum guide qui est souvent mal interprétée.

Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement

Contrairement aux idées populaires, le product owner n’est pas responsable du produit réalisé ! En effet, c’est bel et bien l’équipe de développement qui en a la responsabilité.

Pourtant, nous voyons souvent les PO tester et valider le rendu final ! Sachez que c’est une très mauvaise pratique (scrumbut) qui peut amener l’équipe de développement à perdre son engagement.

D’ailleurs, vous pouvez regarder la vidéo de la minute agile qui explique pourquoi c’est une mauvaise pratique :

En fait, le product owner a la responsabilité de fournir les meilleurs items pour que l’équipe de développement puisse livrer des éléments de grande qualité ; et il saura prioriser de façon à ce que les éléments livrés aient un maximum de valeur.

Responsable de la gestion du backlog

Le product owner est le « seul » responsable de la gestion du backlog. Il peut déléguer certaines tâches de gestion de son backlog à l’équipe de développement mais gardera toujours la responsabilité des résultats.

Le product owner sera ainsi responsable de :

• fournir des items clairs, complets et compris de tous
• d’organiser et de prioriser le contenu de son backlog
• d’optimiser la valeur que pourra délivrer l’équipe de développement
• rendre visible le backlog, la vision du produit et le travail imaginé pour les prochaines itérations

Comme vous pouvez le constater, le product owner est en aucun cas responsable du résultat final. Cependant, si le résultat final n’est pas en adéquation avec sa vision initiale, il en est peut-être la cause ; cela demandera peut-être d’affiner la gestion de son backlog et des items de celui-ci.

Malgré les responsabilités décrites ci-dessus, la façon de tenir ce rôle peut être légèrement différente selon les contextes.

Sprint d’un Product Owner

Maintenant que nous connaissons clairement les responsabilités de ce product owner, il est intéressant de voir comment cela se traduit pendant un sprint. Selon les contexte, il peut évidemment y avoir quelques différences par rapport à cette présentation.

Sprint Planning Meeting

Le Product Owner (PO) doit tenir cette réunion d’ouverture de Sprint. Il commence en premier lieu par présenter l’objectif du sprint qu’il a imaginé. Cet objectif sera négociable par l’équipe de développement si celle-ci pensent qu’il n’est pas atteignable.

Le PO propose ensuite l’ensemble des user stories qui répondront à l’objectif du sprint. Même si il peut profiter de la prédictibilité pour avoir une idée de la capacité de faire de l’équipe de développement, il ne devra pas les forcer à prendre tous les items qu’il avait imaginé ; en effet, seule l’équipe de développement est en droit de valider sa capacité de faire durant le sprint qui démarre.

Le product owner pourra répondre aux questions de l’équipe de développement lors de cette cérémonie pour l’aider  à mieux planifier son sprint.

Pour en savoir plus : Sprint Planning – comment mieux la faire ?

Daily Meeting

La présence du Product Owner à la daily n’est pas souhaitée bien qu’elle ne soit pas interdite. Cependant cela amène souvent à des dérives et peut aussi mettre en lumière des problèmes de transparence. Si l’équipe scrum a un management visuel de grande qualité, toutes les informations nécessaires pour le PO y seront présentes.

Article : Pas de Product Owner à la Daily Scrum, mais…

Sprint Review

En général, le product owner anime la sprint review ; le scrum master le secondera pour faciliter le bon déroulement de la cérémonie. Moi personnellement, j’aime beaucoup la présentation en duo qui montre que le scrum master et le PO sont liés et complices.

Une sprint review se prépare pour être propre avec éventuellement des slides (si possible non chargées). Le product owner va profiter de cette réunion pour voir le ressenti de ses clients, d’obtenir du feedback des utilisateurs et pour tenter de répondre à l’ensemble de leurs questions

Sprint Retrospective

Dans certaines équipes , on peut constater une présence limitée du PO ; cela amène souvent à une difficulté d’intégration de ce PO au sein de l’équipe scrum. Cependant, cela ne doit pas remettre en cause sa présence dans la sprint retrospective car il est un élément essentiel au bon déroulement du projet.

Refinement Meeting

Le PO va proposer des user stories à l’équipe de développement afin d’affiner leur contenu. L’affinage se fait en équipe et ne sera pas le travail du product owner seul. Quand e travail est fait, il n’est pas rare de voir l’équipe de développement estimer la user story lors de cette cérémonie.

Les petites choses à connaitre sur le product owner

Mise à jour du sprint backlog

Parfois, le product owner devra revoir les items présents dans u nsprint backlog. Il pourra ajouter et/ou supprimer des items de celui-ci en gardant sous les yeux l’objectif du sprint. Peu importe le type de demande (user story, bug…), ils ne devront pas mettre en péril l’objectif du sprint.

Le product owner fantôme

Si dans certaines entreprises le PO n’est pas présent au sein de l’équipe Scrum, je recommande vraiment que celui-ci soit installé avec l’équipe afin qu’il fasse vraiment parti de l’équipe.

Le manque de présence va apporter son lot de problèmes :

• moins d’engagement de l’équipe de développement
• deux silos : po et équipe de développement
• ajout de pertes de temps
• risque de conflits augmenté
• …

Vous pouvez regarder la vidéo de la minute agile qui explique pourquoi c’est une mauvaise pratique :

Pour le product owner, les clients avant tout

Le product owner va régulièrement rencontrer les clients (métiers) de l’équipe et les utilisateurs afin de rédiger leurs différentes demandes sous forme de user stories.

La priorisation avancée du backlog

Dans certains contextes, le product owner peut mettre en place une petite réunion de priorisation avec les parties prenantes et les sponsors avec l’aide du scrum master. Cela permet d’impliquer ces acteurs importants au bon déroulement du projet et de partager encore plus sur la ligne directrice du projet.

Il utilisera une notion de « valeur business » sur ces items qu’il pourra définir avec les parties prenantes et/ou utilisateurs afin d’avoir une priorisation très axée sur la valeur.

Le product owner peut arrêter un sprint

Dans quelques cas rares, le PO peut prendre la décision d’arrêter un sprint ; en effet, il pourra prendre cette décision quand il verra que l’équipe de développement n’est plus en capacité d’atteindre l’objectif fixé en sprint planning.

Quelles seront les qualités du Product Owner

Pour commencer, voici la liste des qualités attendues d’un PO que nous expliquerons plus en détail à la suite :

• bon communiquant
• s’intéresse et participe à la stratégie du produit
• savoir dire « Non »

Bon communiquant

En effet, le PO devra être un très bon communiquant et une personne plutôt appréciée par la majorité des clients. Ce sera difficile pour lui d’exercer son rôle correctement si il n’est pas un bon communiquant.

Bon stratège

Dans certaines entreprises, on lui demandera de connaître les coûts des nouvelles demandes. Il pourra s’aider d’indicateurs en général facilités par le scrum master mais entretenus par l’équipe de développement pour réussir à mettre un coût à chaque nouvelle demande.

Savoir dire « Non »

En effet, un PO doit savoir dire « Non » car sinon son backlog finira par être irréalisable. Il est assez rare de voir autant de demandes que de capacité à faire. Ce mot n’est pas si simple à dire dans certains contextes mais il devra y arriver d’une certaine façon.

Ainsi, il faut comprendre que les gros backlog ne sont pas simples à gérer pour le product owner. Cela impliquera qu’il saura s’organiser ; il lui faudra également avoir une bonne vision du produit pour savoir exactement où l’amener.

Conclusion Product Owner

Pour conclure, le poste de PO que j’ai décris brièvement dans cet article n’est pas le rôle le plus facile à tenir mais il est vraiment très intéressant.

Est-ce que vos product owner font aussi d’autres tâches liées au contexte de votre entreprise ?

Liens utiles :

scrum roles (en)
Le PO au service de la stratégie et la vision du produit
Le board du PO