37 tâches qui font partie du boulot de Product Owner

Auteur : Bernd Schiffer
Source : 37 Tasks for a Product Owner’s Job
Date : 29/11/2011

---

Traducteur : Fabrice Aimetti
Date : 06/12/2011

---

Traduction :

Product Owner est un boulot à temps plein

Contrairement au rôle du Scrum Master pour lequel on se demande souvent s'il s'agit d'un boulot à temps plein, on ne remet pratiquement jamais en question le fait que le rôle du Product Owner est, quant à lui, un boulot à temps plein. Une exception : Roman Pichler a présenté "Le Product Owner à temps partiel" dans son livre Agile Product Management with Scrum.
Cependant, je constate que beaucoup de Product Owners ont des problèmes pour se concentrer sur leur travail. Ils font souvent partie d'une sorte de service spécialisé, avec beaucoup d'engagements qui ne sont pas directement liés au produit qu'ils devraient développer au sein de l'équipe Scrum.
Le Product Owner est un emploi à temps plein. Jetez un coup d'oeil à ces 37 tâches, je dirais qu'elles font partie du boulot d'un Product Owner (☼ = symbole explicite d'une collaboration étroite avec l'équipe de développement) :
Le Quoi

• Produire et ajuster la vision du produit.
• Ecrire de nouvelles user stories (☼).
• Découper les user stories qui sont trop grosses (☼).
• Spécifier les critères d'acceptation pour chaque user story (☼).
• Ecrire les tests d'acceptation (☼).
• Ordonner le backlog du produit (selon le ROI, le modèle de Kano, le rapport coût-valeur, la méthode MoSCoW, etc.).
• Planifier la release.
• Toiletter le backlog du produit (pensez INVEST et DEEP (fr)).

A l'extérieur

• Observer, analyser et en apprendre plus sur le marché.
• Observer, contacter, analyser et en apprendre plus des clients et utilisateurs finaux du produit.
• Rester régulièrement en contact avec toutes les parties prenantes du produit.
• Faire votre rapport d'avancement à la direction et aux parties prenantes (avec un burndown de release par exemple).
• Partager des idées au sujet du produit avec toute l'entreprise (micro-blogging, blogs, conférences internes, etc.)

Leadership

• Décider ce qu'il faut ou non construire (☼).
• Donner du feedback à l'équipe de développement :
  • pendant le sprint, sur le travail accompli par l'équipe de développement
  • sur leurs processus et interactions.
• Faire des Gemba Walks.
• Réclamer et motiver le déploiement en un seul clic pour réduire les coûts de transaction.
• Réclamer et motiver un build de 10 minutes pour conserver un feedback rapide.
• Réclamer et motiver la possibilité d'activer/désactiver les fonctionnalités pour garder de la souplesse.
• Fournir et maintenir à jour tous les numéros de téléphone de l'entreprise pour que l'équipe de développement participe à la prise de décisions éclairées concernant le produit et ses clients.

Participer

• Participer aux réunions Scrum :
  • Fournir l'objectif du sprint et de nouvelles stories lors de la planification du sprint.
  • Donner du feedback concernant l'atteinte de l'objectif du sprint lors de la revue de sprint.
  • Réfléchir et prendre des actions comme un membre de l'équipe lors de la rétrospective du sprint.
  • Informer, aider et apprendre des choses lors de la mêlée quotidienne.
• Aider l'équipe à améliorer en permanence ses processus.

Apprendre

• Continuer à apprendre sur tout ce qui concerne l'Agilité (par exemple rendre visite à des groupes d'utilisateurs, assister à des conférences, lire des livres, écrire sur des blogs, etc.).
• Échanger en permanence avec les autres Product Owners de l'organisation (par exemple au travers de communautés de pratiques).
• Jouer avec le produit.
• Apprendre à affiner le flux de valeur du produit, par exemple avec l'approvisionnement en amont, le marketing et les ventes en aval.
• Mesurer les progrès accomplis (par exemple la valeur livrée aux clients à l'issue de chaque sprint).

Divers

• Aider l'équipe à créer des radiateurs d'information.
• Enchanter les clients.
• Trouver une pertinente (☼)
  • définition du fini
  • définition du prêt.
• Resserrer chaque boucle de feedback concernant le produit (par exemple livrer souvent, livrer tôt, parler aux clients, Produit Minimum Commercialisable, etc.).
• Transformer les idées en nouveaux produits, idéalement des MVPs.

Vous avez réalisé et/ou pris en considération tout ce qui était mentionné ci-dessus ? Vous êtes assis au même endroit que le reste de l'équipe, vous êtes totalement autonome et votre produit est un énorme succès ? Bravo ! Sortez faire une méga-fête avec votre équipe !

Le Product Owner a la responsabilité de maximiser la valeur du produit et le travail de l'Equipe de Développement. – Scrum Guide (fr)