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.
C’est une définition qui me convient. Je me reconnais bien là 😉
@ramuncho
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/
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 ?
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 🙂
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
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,
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
Hello,
Pensez vous qu’un Product Owner doit obligatoirement venir du « métier » de l’entreprise pour être bon ?
exemple : Entreprise dans le marketing digital, product owner qui travaille dans la finance d’entreprise.
A priori il ne connaît rien à ses utilisateurs mais c’est un très bon PO , qu’est ce qu’on fait 🙂
Cordialement,
Florian Maignan
Bonjour,
Je vous prie d’excuser ma question si pas pertinente mais pourriez vous m’expliquer ce qu’est le rôle d’un épic owner et la différence avec un PO.
Part avance merci pour votre retour 😉
Je n’ai jamais entendu parler ni lu au sujet d’un Epic Owner, je ne suis donc pas en mesure de vous aider, désolé
Bonjour,
Je travaille dans une entreprise qui a adopté récemment cette organisation. Personnellement, je la trouve désastreuse. Depuis que nous avons un PO, nous n’avons plus aucune livraison intéressante de ce qu’on appelle maintenant le « Produit ».
En lisant votre définition du PO, je comprends un peu mieux pourquoi. Nous avons un PO professionnel, dont le métier est d’être PO depuis toujours. Il vient du « technique ». Je ne vois pas comment il peut comprendre les attentes et besoins d’utilisateurs d’un métier dont il ne connait rien, et mesurer les bénéfices apportés par des fonctionnalités dont il ne peut pas réellement approcher la finalité.
C’est comme si on demandait à un physicien nucléaire de faire du pain. Ça n’a pas de sens.
Je suis très déçu par cette méthodologie, et je regrette de l’avoir adoptée.
Bonjour Claude,
Je comprends la déception.
Selon tes propos, il s’agit d’un pb de casting du « PO » et non un pb de méthode?
Avez vous remplacer le PO par qn qui fait le job ? 🙂
Bonne continuation
Bonjour,
Je suis chef de projet et MOA. Je me suis formée aux fondamentaux d’Agile et précisément au Scrum. J’attends la formation pour être PO.
je suis intéressée par la méthode, à cause de la décomposition du travail dans des sprints, et l’organisation.
j’ai du mal avec ce rôle, mais suivant vos échanges, je crois que si le PO croule sous le poids de son travail, il peut en déléguer à un autre; le proxy PO dont on parle. Mais la relation va paraitre bizarre avec la Dev-team.
Je suis d’avis avec le fait d’avoir un PO stratégique qui va garder de toutes les façons sa relation avec la Dev Team, et des PO opérationnels qui eux-aussi côtoient la Dev-Team et rendent compte au PO Stratégique. MAis comme ils sont opérationnels, c’est aussi eux qui récupèrent le besoin utilisateur et les remettent au PO stratégique pour mettre à jour et revoir la priorisation des user story (le grooming ).
Je ne sais pas si en faisant ceci, nous gardons encore la substance première du Scrum?
C’est là que je constate que le Scrum reste pas mal pour des projet de taille réduite.
Qu’en pensez-vous?
A vous lire.
Cordialement
Marina
bonjour,
est-ce que l’équipe agile (hormis le PO) doit participer au PB? mise à jour, compléments sur les US ou alors cette responsabilité incombe telle au PO? quel est le rôle de l’équipe?uniquement spécifier et délivrer?MERCI
Le PO est à l’initiative des User Story (Fonctionnalités visibles des utilisateurs), et ces User Story seront surement complétèes lors de la conversation avec les équipiers (lors d’un Poker Planning par exemple).
Les Technical Story sont à l’initiative des équipiers (aidé par le Scrum Master), ces Story sont expliquées au PO puis positionnées dans le Product Backlog (la priorisation dans le PB reste une prérogative du PO ;))