Product Owner … qui es-tu ?

Je partage avec vous ma vision du rôle du Product Owner, tous vos feedbacks sont les bienvenus 🙂

Rôle du Product Owner

Le Product Owner (ou PO) est avant tout un rôle initialement définie dans la méthodologie Scrum et maintenant généralisé à l’ensemble des méthodes dites « Agile ». Ce rôle est généralement tenu par un individu unique, mais il est courant de voir également une équipe de PO assurer cette mission avec succès, sous réserve que cette équipe de PO tienne un discours commun et cohérent auprès de l’équipe de réalisation.

Le PO est un membre à part entière de l’équipe Scrum dont la responsabilité principale est de définir un produit qui apportera le maximum de valeur métier aux utilisateurs dans le temps et le budget impartis au projet.

Le Product Backlog

L’outil principal utilisé par le PO est le Product Backlog (ou PB) qui est la liste ordonnée des éléments constitutifs du produit. La priorité des éléments est définie suivant 4 caractéristiques : leur valeur métier, leur effort de réalisation, leur risque et la connaissance technique ou métier apportée par leur mise en œuvre. Chaque PO définit des règles de priorisation, basées sur 1 à 4 de ces caractéristiques, généralement valables pour la durée de réalisation d’une version (un produit se décompose en plusieurs versions).

Le PB sera réalisé par l’équipe de réalisation, itération après itération, dans le respect absolu de l’ordre positionné par le PO. Cette liste sera amendée (ajout ou suppression) en fonction des feedbacks récoltés auprès des utilisateurs à chaque itération, mais ces changements doivent survenir entre les itérations pour ne pas perturber l’équipe durant l’itération en cours.

L’évolution du Product Backlog sur la base des retours utilisateurs permet de garantir que le produit final répondra exactement aux attentes des utilisateurs. Comme le budget est généralement contraint et que chaque changement représente un coût, il est de la responsabilité du PO de discuter régulièrement avec les utilisateurs pour bien évaluer la valeur des changements demandés au regard des fonctionnalités à venir, et choisir l’un ou l’autre en fonction du modèle de valeur du produit.

L’Activité Principale du Product Owner

La création du PB et son maintien (ou « grooming » en anglais) sont les activités principales du PO, elle n’est pas facile car il lui faut récolter de nombreuses informations sur le produit :

  • Identifier les attentes des utilisateurs et les bénéfices que le produit leur apportera
  • Décrire avec le maximum de détails les utilisateurs et/ou clients du produit
  • Identifier les fonctionnalités attendues et sélectionner celles qui apportent le plus de valeurs ou de bénéfices aux utilisateurs pour définir et planifier les releases/versions du produit
  • Décrire chaque fonctionnalité retenue sous forme d’une User Story suffisamment petite pour être implémentée en 1 seule itération, sans oublier d’y associer les critères d’acceptation indispensables à sa bonne compréhension par l’équipe.
  • Comprendre les Technical Story proposées par l’équipe de réalisation (besoins non fonctionnels mais indispensable – ex : Migration de version d’une base de données) et les Bug Story (ou « bugs connus »)
  • Prioriser toutes les Story au sein du Product Backlog
  • Maintenir le Product Backlog et chercher en permanence à maximiser la valeur métier pour les utilisateurs
  • Accepter ou refuser les Story implémentées par l’équipe de réalisation

De nombreuses techniques, propres au métier du Product Owner, permettent de faciliter le travail du PO. Parmi celles-ci nous citerons « Story Mapping », « Product Box », « Impact Mapping », « Personas », « Blitz Planning » et « Remember the Future ».

Autres Activités du Product Owner

Si l’élaboration et l’évolution du Product Backlog représentent des activités primordiales et consommatrices de temps, ce ne sont pas les 2 seules activités dévolues au PO, car il ne faut pas oublier les suivantes :

  • Elaborer la Vision du Produit pour la version en cours
  • Partager cette Vision avec l’équipe de réalisation et leur communiquer pourquoi le produit est utile
  • Montrer aux décideurs / parties prenantes que cette vision est dans la ligne de la stratégie de l’entreprise
  • Communiquer sur l’avancement de la réalisation du produit auprès du management et des utilisateurs
  • Récolter les feedbacks des utilisateurs
  • Répondre aux demandes de clarification émises par l’équipe de réalisation sur les Story en cours de réalisation durant l’itération.
  • Contribuer aux réunions Scrum avec l’équipe de réalisation et le Scrum Master
  • Réaliser ou organiser le déroulement des Tests Utilisateurs/Métier de la version
  • Evaluer le fonctionnement des versions précédentes mises en production et en cours d’utilisation
  • Mener une réflexion stratégique préparatoire des versions à venir

Et même parfois

  • Assurer la formation des utilisateurs
  • Promouvoir le produit auprès d’autres instances (Directions métier, Filiales …)
  • Evaluer les opportunités du marché
  • Vendre le produit à des clients et ramener des commandes fermes !

Un Rôle à Temps partiel ?

La liste des activités du Product Owner décrites ci-dessus amène naturellement à la conclusion que le rôle de PO nécessite un investissement important qui conditionne très fortement le succès du produit. Cette charge de travail conséquente justifie souvent la mise en œuvre d’une Equipe PO ou plusieurs individus assurent en commun le rôle unique de Product Owner du produit.

Une cause d’échec des méthodes Agiles régulièrement identifiée est une disponibilité insuffisante du Product Owner. L’échec peut se caractériser par la réalisation d’un produit qui ne répond pas aux attentes des utilisateurs (absence de feedbacks), par le déploiement d’un produit trop complexe (orientation trop technique) ou par un périmètre incomplet et  non utilisable (absence de modèle de valeur et de priorisation).

Product Owner : Je veux me Former !

Suivre une formation spécifique pour Product Owner est une très bonne façon pour commencer à apprendre les différentes, techniques de définition de produit, de rédaction de Story et d’élaboration du Product Backlog.

Je propose depuis plusieurs années maintenant une formation spécifique pour Product Owner sur 2 jours qui est largement plébiscité par les participants qui l’ont suivi (Prochaine session : 6 et 7 mai 2013 sur Grenoble)

Cette formation est également labellisée par la Fédération Agile des Formateurs Francophones.

9 pensées sur “Product Owner … qui es-tu ?”

  1. Bonsoir Alex,

    Je trouve que la définition du poste n’est valable aujourd’hui que sur des projets de taille réduite, avec 3 à 5 développeurs maximum. Au delà, le rôle ne suffit plus, et doit être remplacé par une « fonction » de Product Management opérée par plusieurs personnes (ce que tu décris comme l’équipe PO).

    Mais néanmoins, la clé de la réussite du Product Management ou du Product Ownership et le fait qu’il n’y ait qu’une seule tête : il faut une personne à la tête de cette équipe, qui soit seul à prendre la décision finale. C’est le Super Product Owner, le Directeur Produit.

    J’ai décris ce rôle ici : http://www.visionproduit.fr/definitions/les-metiers-de-la-gestion-de-produit-web/directeur-produit-internet/

  2. Alex, je partage totalement ton point de vue sur la nécessité d’une précence forte du PO dans l’équipe produit. Le problème vient en général du fait que les personnes de l’organisation qui ont vraiment le mandat suffisant pour décider seul des priorités (sans demander à sa ligne hiérarchique) n’ont souvent pas le temps de s’impliquer plus que quelques heures par semaine. C’est vraiment insuffisant pour bien tenir son rôle de PO…
    Dans ces cas-là, je conseille la mise en place d’un PO « stratégique » et d’un ou plusieurs PO « opérationnels ». Les PO opérationnels sont dans l’équipe et sont en relation fréquente avec le PO stratégique. Le PO stratégique partage la vision produit avec les PO opérationnels, valide les propositions de macro user stories (epics) et de priorisation macro des PO opérationnels. Les PO opérationnels ont en charge le grooming du backlog, la rédaction des tests d’acceptance, la recette du produit, bref, les tâches quotidiennes dont le PO est responsable.
    Je n’aime pas le terme de proxy PO, car ce que je comprends dans ce terme, c’est que le proxy PO est une frontière entre le PO et l’équipe, et pour moi, ce n’est pas une bonne chose. Le PO stratégique et l’équipe doivent garder des occasions de se rencontrer et d’échanger, par exemple les démos.
    Qu’en pensez vous ?

    J’aime bien cette notion de PO stratégique et PO Opérationnel, car je n’aime pas non plus le terme de PO proxy 🙂
    Alex

  3. Bonjour Alexandre,

    Merci pour cet article dans lequel je me reconnais tout à fait en tant que PO chez un éditeur.

    Je m’en suis même servi pour formaliser une fiche de poste PO et recruter avec succès un nouveau PO dans le cadre de la croissance de mon organisation et la constitution d’une nouvelle équipe. Cette fiche a permis à la société de recrutement que j’avais mandaté de bien cibler le profil recherché et de me proposer des candidats très intéressants, y compris des candidats qui n’avaient pas d’expérience de PO en tant que tel…

    Merci encore 🙂

  4. Bonjour,

    L’article est très intéressant et les commentaires le sont aussi.
    Comme Emilie, on est arrivés à la même conclusion; pour jouer efficacement le rôle de PO et être disponible, il faut le créer ce rôle.
    Je suis disponible pour échanger avec vous par rapport à cette démarche et notre vécu.

    Au plaisir,
    Slim

  5. Bonjour,

    Qui peut m’aider à différencier concrètement entre le rôle joué par un AMOA et un PO?

    Aussi, j’aimerai savoir si les rédactions des spécifications fonctionnelles ne sont pas nécessaires dans la démarche Scrum, sinon quel est le substitut ou l’éventuelle alternative de ces documents, qui à mon sens relèvent d’une grande importance.

    Dans le plaisir de vous lire,

  6. Bonjour
    Je ne pense qu’il soit souhaitable de comparer ces rôles car ils sont issus d’approches basées sur des modèles de valeurs différents.
    Le rôle du PO est parfois difficile à assumer pour 1 seule personne, même à plein temps, et le PO pourra donc être aidé dans cette activité.
    Il y a donc une « équipe PO » dont les membres se partagent le travail à faire. Et plutôt que de réduire l’activité de ces personnes à un rôle (comme AMOA), je préfère les considérer « Equipier PO » avec une responsabilité collective de jouer le rôle de PO.
    Pour ce qui est des spécifications fonctionnelles, je pense que n’importe quelle formation Scrum vous donnera la réponse 🙂
    Et merci pour votre commentaire
    Alexandre

Laisser un commentaire

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