Les 10 responsabilités du Product Owner @ Agilex : Agilité et Expertise

Les 10 responsabilités du Product Owner

Posté le mars 24th, 2010 Alexandre Boutin 6 commentaires

Voici 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

Scrum
6 réponses à “Les 10 responsabilités du Product Owner”
1. Ludovic 24 mars 2010 à 17:43
  
  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. Les tweets qui mentionnent Les 10 responsabilités du Product Owner @ Agilex : Agilité et Expertise -- Topsy.com 24 mars 2010 à 18:01
  
  [...] Ce billet était mentionné sur Twitter par Julien Lancelot et ludovic meurillon, ludovic meurillon. ludovic meurillon a dit: Les 10 reponsabilité du Product Owner http://www.agilex.fr/2010/03/les-10-responsabilites-du-product-owner/ [...]
3. Sylvain 24 mars 2010 à 22:55
  
  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…
4. Ludovic 25 mars 2010 à 10:32
  
  @Sylvain je te suis dans cette voie dans ce cas du moment qu’on peut libérer une place.
5. nicolas 1 avril 2010 à 11:06
  
  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)
6. Liens et actus 13 avril 2010 à 22:46
  
  [...] Les dix responsabilités du Product Owner [Développement] [...]
Laisser une réponse

Nom (obligatoire)

Adresse de messagerie (ne sera pas publiée) (obligatoire)

Site web