Que fait un Product Owner de ses journées ?

Le Product Owner

Nous avions vu le rôle du Scrum Master, 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 qui est 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 et à quoi ressemble ses journées lors d’un Sprint.

Sprint d’un Product Owner

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

Sprint Planning Meeting

Il est très important pour un Product Owner de tenir cette réunion d’ouverture de Sprint car elle a pour but de préparer l’ensemble du Sprint en équipe. Il va proposer l’ensemble des User-Story qui seront à traiter dans le courant du Sprint qui ont déjà été estimée par l’équipe de développement. Il présente uniquement les User-Story qu’il aura lui même priorisé en respectant la capacité de faire (fournit grâce à des calculs magiques par le Scrum Master).

J’ai volontairement fait le choix de sortir l’estimation des User-Story de cette réunion car je pense qu’aujourd’hui la Refinment Meeting (Grooming) apporte tellement à une équipe Scrum qu’elle est presque obligatoire.

Le PO est le seul à choisir les User-Story à traiter.

Dès que le PO a présenté l’objectif du Sprint et l’ensemble des User-Story à traiter, il doit rester disponible car il arrive parfois que les équipes de développement se posent encore des questions sur certaines User-Story mais 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.

Même si ça ne devrait jamais arriver mais que le contexte d’un grand nombre d’entreprise l’oblige un peu, il est le seul à pouvoir ajouter des demandes dans un Sprint ; il profitera de la Daily pour indiquer cet ajout.

Dans ce dernier cas, je vous recommande grandement de ne pas faire un remplacement de ticket mais 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.

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.

Lorsqu’il y a beaucoup de client pour l’équipe Scrum, il est conseillé qu’il tienne toutes les semaines avec le Scrum Master, une petite réunion de priorisation entre les métiers afin que les priorités soient connues et acceptées par tous.

Sprint Review

La Sprint Review peut être présenté par le Product Owner et/ou le Scrum Master. Moi particulièrement, j’aime bien la présentation en duo qui montre que les deux 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 les équipes où le PO est peu présent, il y a beaucoup de chance qu’il soit moins intégré dans l’équipe ; dans ce cas sa présence dans la Sprint Retrospective peut-être discutable.

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.

Refinment 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 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

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

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

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.

Un Product Owner 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.

Le PO devra être bien organisé car les gros backlog ne sont pas simples à gérer et il lui faudra avoir une bonne vision du produit pour savoir exactement où l’amener.

Conclusion

Le Poste de Product Owner 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 ?

Laissez une réponse