Product Owner (PO)

Ecrit par << Paquet Judicaël >>

Le Product Owner (PO)

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.

Comme son nom l’indique, le Product Owner (dit PO) est le propriétaire du produit ; il est responsable du produit livré et des plannings qui y sont associés. C’est un des 3 rôles clé dans le Scrum.

C’est synthétique mais nous allons détailler dans cet article, tous les rôles de ce Product Owner ; à quoi ressemble ses journées lors d’un Sprint ?

Voici quelques articles écrit ultérieurement sur le Product Owner qui pourraient également vous intéresser :

Le PO au service de la stratégie et la vision du produit
Le board du PO

Sprint d’un Product Owner

Le rôle peut être légèrement différent selon les contextes mais voici en général à quoi ressemble un Sprint d’un Product Owner.

Sprint Planning Meeting

Le Product Owner (PO) doit tenir cette réunion d’ouverture de Sprint. Il commence en premier lieu par présenter les objectifs du sprint afin d’aligner l’ensemble de l’équipe autour d’un même objectif.

Le PO propose ensuite l’ensemble des User-Stories qui seront à traiter dans le courant du Sprint qui ont déjà été estimées par l’équipe de développement. Il présente uniquement les User-Stories qu’il aura lui même priorisées en respectant la capacité de faire.

Dans le Scrum actualisé, l’estimation des items (user-story par exemple) se fait lors de la Product Backlog Refinement ; dans les anciens scrum guide, cette estimation se faisait lors de la sprint planning.

Le Product Owner (PO) est le seul à choisir les User-Stories à traiter.

Il doit rester disponible tout au long du sprint car il arrive parfois que les équipes de développement se posent encore des questions sur certaines User-Stories ;  cependant il peut faire d’autres choses comme ses tâches quotidiennes.

Daily Meeting

La présence du Product Owner à la Daily Meeting n’est pas obligatoire mais je la recommande vivement. En étant présent, il est bien informé de l’avancement et peut apporter dans certains cas des compléments d’information.

Seul le Product Owner pourra ajouter une demande au sprint. Il peut profiter du Daily pour indiquer l’ajout de la demande. Pour rappel, la demande ajoutée devra répondre aux objectifs du sprint annoncés en sprint planning.

Si l’ajout ne correspond pas aux objectifs du sprint, je vous recommande grandement de l’ajouter en montrant bien que c’est un Impediment (perturbation). D’ailleurs en cas de Burndown Chart, ce ticket ne sera pas pris en compte dans le décompte.

Le Product Owner, pendant le reste des journées

Si dans certaines entreprises le Product Owner 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 Product Owner va régulièrement rencontrer les clients (métiers) de l’équipe afin de rédiger leurs différentes demandes sous forme de User-Story. Dans les équipes qui font du Scrum avancé, les Product Owner écrivent même les tests d’acceptances de chaque User-Story.

Dans certains contextes, le Product Owner peut mettre en place une petite réunion de priorisation avec les parties prenantes et 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.

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 Product Owner sont liés et complices.

Une Sprint Review se prépare pour être propre avec éventuellement des slides. Le Product Owner va plutôt gérer la partie présentation du produit alors que le Scrum Master va souvent fournir des indicateurs. Il va profiter de cette réunion pour voir le ressenti de ses clients 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.

Pour ma part, je suis partisan des PO totalement insérés dans l’équipe et qu’ils soient des membres de l’équipe ; dans ce cas la présence du Product Owner est indispensable. D’ailleurs l’absence du PO peut avoir dans ce cas des effets plutôt négatifs sur l’ensemble de l’équipe.

Refinement Meeting (Grooming)

Comme je le disais plus haut, pour moi cette réunion que je conseille une fois par semaine par session d’une heure maximum permet d’alléger considérablement la Sprint Planning Meeting mais aussi d’améliorer considérablement le travail d’organisation du Product Owner (PO) .

Le PO va proposer des user-story à l’équipe de développement qui posera des questions si elle ne comprend pas, qui la rejettera si la user-story n’est pas complète et qui estimera les user-story complètes. Le Product Owner devra expliquer voire modifier en live les user-story pour qu’elles soient bien comprise par l’ensemble de l’équipe de développement.

Le PO devra retravailler les user-story rejetées avec les clients concernés afin de représenter une version complète et compréhensible de la user-story.

Pourquoi un Product Owner intégralement intégré ?

Quand le Product Owner est physiquement avec le reste de l’équipe et qu’il est un membre à part entière de l’équipe, il tisse par défaut des liens avec l’ensemble de l’équipe. Cela aura en conséquence de diminuer considérablement les éventuels conflits et d’avoir en cas de désaccord avec l’équipe de développement une vraie discussion constructive.

Il n’est pas rare de voir les intérêts du PO et de l’équipe de développement diverger sur certains points.

Quelles seront les qualités du Product Owner

Voici la liste des qualités attendues d’un Product Owner :

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

Bon communiquant

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

Il faut bien comprendre que ce rôle est stratégique en Scrum ; il est le point d’entré avec l’équipe de développement.

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 géré par le Scrum Master pour réussir à mettre un coût à chaque projet.

Savoir dire « Non »

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.

Les gros backlog ne sont pas simples à gérer pour le Product Owner. Cela impliquera qu’il saure s’organiser ; il lui faudra également avoir une bonne vision du produit pour savoir exactement où l’amener.

Conclusion Product Owner

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 ?

4 réponses sur “Product Owner (PO)”

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.