Les 10 responsabilités du Product Owner

top-ten-goldVoici ma définition des 10 responsabilités principales du Product Owner (proposé sous forme de liste non priorisée) :

  1. Définir et faire partager la vision du produit (A l’aide du Product Charter par exemple)
  2. Représenter le client/utilisateur auprès de l’équipe
  3. Communiquer en externe sur l’avancement (Utiliser la vélocité comme métrique principale)
  4. Créer et maintenir le Product Backlog (Le quotidien du Product Owner)
  5. Prioriser le Product Backlog (Définition et utilisation d’un modèle de valeur métier)
  6. INVESTir dans les exigences (Rédaction complète et vérification à l’aide du modèle INVEST)
  7. Participer aux meetings Scrum de l’itération (Planning, Démo et Rétrospective) et éventuellement au Stand Up
  8. Accepter ou refuser le travail réalisé (Et donc faire « gagner » les points ou pas)
  9. Ne rien changer durant l’itération (Si, si, c’est une responsabilité)
  10. Etre disponible sur demande de l’équipe

Il m’a été difficile de faire le tri et de réduire à 10 éléments cette liste, donc si vous souhaitez rajouter quelque chose, il faudra également indiquer ce que vous aller retirer … pour que le total fasse toujours 10 🙂

9 réflexions sur « Les 10 responsabilités du Product Owner »

  1. Perso j’aurais fusionnées la 4 et la 5 en un « Alimenter et maintenir le product backlog avec priorités métiers »

    Et je rajouterai dans la place libérée : « Alimenter le système de gestion d’anomalie (Jira/Mantis) »

  2. Ludovic, c’est trop facile de fusionner pour gagner de la place 😉
    Créer des éléments du backlog et savoir les prioriser à l’aide d’un modèle de valeur métier sont 2 choses différentes. Je ne suis pas pour les fusionner. Sinon, on pourrait dire que les exigences font parties du backlog, alors on fusionner la numéro 6…

  3. @Sylvain je te suis dans cette voie dans ce cas 🙂 du moment qu’on peut libérer une place.

  4. Utiliser la vélocité comme métrique principale : peux tu mieux détailler ce que tu entend par là. Je pense que si c’est mal compris cela peut être très dangereux. La vélocité est une variable interne à l’équipe car incompréhensible pour une personne extérieure qui va sinon rapidement croire que cela reflète la productivité de l’équipe…
    La pression va alors apparaitre sur le PO pour améliorer la productivité de l’équipe et cela devient vite parasite.
    Par contre dériver de la vélocité ce que contiendront les futures versions (pour autant que l’on ait fait estimé la backlog suffisamment loin et que l’on sache correctement mettre des buffers pour pouvoir insérer ce qui n’est pas encore identifier par le PO) a du sens. C’est un moyen de construire une roadmap un poil réaliste.

    Alexandre : C’est clairement la 2ème approche que tu mentionnes que je soutiens. Le PO n’a pas a communiquer sur l’avancement d’un sprint vers l’extérieur (par contre il doit être informé par l’équipe de cet avancement via le burndown chart d’itération). Et ce que je recommande, c’est d’utiliser la vélocité comme mesure d’avancement de la roadmap (Ex : 128 points sur 210 ont été fait, et compte tenu de la vélocité actuelle de l’équipe , j’estime que l’on sera prêt pour le 14 septembre)

  5. Ping : Liens et actus
  6. Bonjour Alexandre,

    Je trouve le dixième point très important et un peu tronqué. Je m’explique : je relie cet item à la première valeur agile – « les interactions plus que les processus et les outils », aux 3C (conversation) et au modèle INVEST (Negociable), et à la notion de « raccourcir les boucles de feedback ». Je pense personnellement que le PO doit pouvoir « voir » les histoires au cours de leur construction pour donner un feedback le plus rapide possible sur les détails de l’histoire. Il ne faut pas attendre que la Story soit en attente de validation par le PO pour qu’il en visualise le résultat final. Il doit co-créer. S’il s’agit d’une interface Web par exemple il pourrait donner un feedback précieux lors de la finalisation.
    Pour cela il doit à mon avis venir chercher ce feedback physiquement auprès de l’équipe en se synchronisant avec celle-ci lors de la mêlée par exemple.

Laisser un commentaire

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