Une journée dans les baskets d’un Product Owner

Le rôle de Product Owner est indispensable au succès d’un produit.

Nous vous proposons de vous immerger dans le quotidien d’un Product Owner pour mieux saisir ses problématiques et pourquoi pas, éveiller de nouvelles vocations !

On vous embarque dans le quotidien d’un Product Owner agile

7h30 - Prêt pour une journée dans les baskets d’un Product Owner ?

Comme tout humain, le Product Owner commence sa journée par un bon café, thé, petit déjeuner lui permettant d’être d’attaque pour assurer sa journée.

9h - La journée commence par le Daily Meeting ou mêlée quotidienne : l’occasion de réunir l’ensemble de l’équipe (équipe de développement, Scrum Master …) pour faire un point sur ce qui a été réalisé la veille, le programme de la journée à venir, d’éventuels points bloquants et le mood de l’équipe. Tout ça en 15 min !

Lors de ce point, Thomas, Data Scientist, partage qu’il vient de terminer la réalisation d’une User Story et sollicite un membre de l’équipe pour planifier une revue technique. D’autre part, Alicia, développeuse Front-End, demande des précisions au Product Owner concernant la User Story qu’elle souhaite démarrer aujourd’hui. Enfin, Michel, UX designer, rappelle qu'aujourd'hui ont lieu les interviews utilisateurs concernant la nouvelle feature super cool.

📚 Lire notre article sur le Daily Meeting

9h15 - C’est d’ailleurs le prochain point auquel assistera le Product Owner aujourd’hui. Avec l’aide de l’UX designer, le Product Owner a sélectionné un panel d'utilisateurs et préparé un plan d’interview pour identifier des pistes de besoins prioritaires qui amélioreront l’expérience d’utilisation de son produit. Il est important que le Product Owner soit présent dans la préparation et le déroulement de ces interviews et futurs ateliers pour qu’il soit imprégné de ces retours utilisateurs lorsqu’il anime le backlog. Pendant 2h, il rencontre trois utilisateurs et prend note de leurs réponses, réactions et émotions.

📚 Lire notre article sur le backlog

11h - Le Product Owner retrouve Alicia, la développeuse Front-End. Il prend 20 minutes pour clarifier le besoin d’une User Story et répondre aux questions concernant les maquettes jointes.

11h30 - Le Product Owner prend une heure pour finir de préparer la réunion d’affinage ou backlog refinement de l’après-midi. Après sélection des User Stories qu’il souhaite aborder, il s’assure de les avoir toutes rédigées correctement sur son outil JIRA. Pour cela, le Product Owner s’appuie sur la Definition Of Ready ainsi que sur le template d’écriture (titre, description, critères d’acceptance, et les tests d’acceptance) construits avec l’ensemble de l’équipe. Les User Stories doivent bien être complètes et claires pour n’importe qui (équipe de réalisation voire clients et utilisateurs) : cela permettra de travailler efficacement lors du backlog refinement.

📚 Lire l'article sur les User Stories et comment les rédiger

📚 Lire notre article sur JIRA.

12h30 - Time to lunch !

13h30 - Thomas, le Data Scientist a finalement pu revoir techniquement la User Story avec un membre de l’équipe de dev. Il faut maintenant la valider fonctionnellement : le Product Owner prend donc quelques minutes pour effectuer les tests qui lui permettent de valider la User Story (Yeah!).

14h - La réunion d’affinage commence ! Toute l’équipe de développement est présente. L’objectif est d’affiner le contenu du Product Backlog afin de préparer aux mieux les User Stories des sprints suivants. Le Product Owner dégaine sa liste de User Stories préparée plus tôt, puis les présente une par une en s’assurant qu’elles sont bien comprises par l’équipe, qui détaille ensuite les tâches techniques nécessaires à la réalisation de chaque User Story. Le Product Owner prend note également des questions et des retours concernant les User Stories moins claires, il devra les retravailler et les représenter lors d’un prochain affinage. Il ressort de ce point avec une liste de User Stories prêtes à être estimées lors du poker planning du lendemain et une liste de User Stories à retravailler.

📚 Lire et tout savoir sur les Sprints Agiles

📚 Lire notre article sur le Poker Planning

15h30 - Animation d’un atelier Buy a Feature avec les équipes métiers. Plusieurs fonctionnalités clés sont identifiées et prêtes pour intégrer le prochain sprint mais au vu de leurs estimations et de la vélocité de l’équipe, le Product Owner a besoin de prioriser. L’atelier Buy a Feature va permettre de prioriser les fonctionnalités en équipe en obligeant à établir une hiérarchie parmi les nombreux sujets disponibles.

17h - Préparation du planning de la revue de sprint : dernière ligne droite, demain c’est le dernier jour du sprint et aura lieu la revue de sprint en présence de l’équipe métier. Le Product Owner fait un bilan des User Stories réalisées (et validées) versus celles planifiées en début de sprint, il s’assure une dernière fois que toutes les nouvelles features sont bien fonctionnelles !

18h30 - Encore une journée remplie pour le Product Owner !

CV idéal d’un Product Owner

Les formations

Il n’y a pas de formation type pour exercer le job de Product Owner même si deux tendances se dégagent en termes de formation :

• école de commerce ;
• école d’ingénieur / d’informatique.

Mais il n’est pas rare de croiser des Product Owners issus d’une reconversion ou d’un beau virage professionnel.

Il est possible d’accéder à des formations facilement pour devenir Product Owner Agile via :

• la certification Scrum officielle ;
• la première formation en ligne francophone dédiée au Product Management, lancée par Hubvisory : Product Manager en e-learning. Elle aborde notamment l’aspect Product Ownership.

Les qualités & responsabilités d’un Product Owner : la théorie

Pour rappel, nos amis Ken Schwaber et Jeff Sutherland, co-auteurs du guide officiel de Scrum, nous énoncent les responsabilités du Product Owner :

• l’expression claire des items dans le backlog produit : un item ou User Story va maturer deux ou trois sprints avant d’être embarqué, le Product Owner va les travailler sans lésiner sur les détails.
• l’ordonnancement des items dans le backlog produit.
• l’optimisation de la valeur du travail réalisé par l’équipe de développement
• l’assurance que le backlog produit est visible, transparent et clair pour tous
• l’assurance que l’équipe de dev comprend l’ensemble des items du backlog produit pour qu’ils soient 100% autonomes.

Et en pratique

Un Product Owner …

… est responsable de la valeur métier apportée par un produit. Chaque User Story doit avoir une valeur business qui, couplée avec l’estimation de l'équipe de développement, donne un ROI et aide à prioriser. La plus grande préoccupation du Product Owner est de délivrer un maximum de valeur le plus tôt possible.

… diffuse la vision produit. En exprimant les attentes des utilisateurs, il s’assure d’aligner les parties prenantes autour de la vision produit. Le Product Owner est chargé de la stratégie du produit : adapter le produit au contexte de l'entreprise, aux besoins utilisateurs, aux contraintes techniques et/ou budgétaires.

📚 Lire l'article sur la Vision Produit

... met les utilisateurs au centre de l’attention. Le Product Owner invite les utilisateurs, les parties prenantes, les sponsors aux différentes revues ou démos pour permettre de recueillir du feedback.

… crée et gère le backlog : écriture des demandes fonctionnelles au fur et à mesure de la vie du produit, et priorisation des User Stories.

... n’est pas là pour dire à l’équipe de dev comment elle doit fonctionner, quel langage elle doit utiliser. Le Product Owner transmet tous les éléments qui permettront l’équipe à réaliser ses choix en fonction du besoin de manière autonome.

… doit être un bon communicant car il a des interactions partout ! Que ce soit avec les divers profils de l’équipe de développement (UX/UI designers, développeurs, Data Analyst, Data Scientist, testeurs, Business Analysts …), les utilisateurs, les équipes métiers, les parties prenantes, ou les sponsors, le Product Owner doit communiquer la vision produit de manière claire. Avoir un bon relationnel facilitera son travail et donc le succès du produit.

... doit être disponible. Il travaille à temps plein sur son produit et est intégré dans l’équipe Scrum. En effet, il doit passer un maximum de temps possible avec l’équipe pour permettre les échanges et questions au fur et à mesure. Cela permet d’impliquer et d’engager l’équipe de réalisation.

… doit être entreprenant, proactif. Si un besoin ou sa valeur n’est pas 100% clair, c’est au Product Owner de provoquer et d’organiser les échanges avec les personnes et les équipes pertinentes pour challenger, approfondir, et valider les User Stories qui en découlent.

… doit savoir dire non ! Le Product Owner doit protéger son produit et son équipe : il arrive que les parties prenantes (équipes métier, sponsor, management) tentent d’imposer des demandes qui n’apporteront pas de valeur au produit, ou qui ne seront pas réalisables rapidement. Le Product Owner doit dire non et expliquer de manière diplomate et constructive pourquoi une telle demande n’est pas dans l’intérêt du produit.

… doit avoir une bonne culture Agile.

… doit maîtriser les outils et méthodologies du Product Management. Ils faciliteront son travail au quotidien.

…connaît les outils de gestion de produits (JIRA, Trello …). L’utilisation d’outils comme JIRA permet de rendre le backlog produit visible, transparent et clair pour tous : le Product Owner peut créer et préparer les User Stories sur 2 ou 3 sprints en avance, il peut les prioriser, construire son story mapping.

… ne doit pas nécessairement avoir un background technique. Dans la majorité des cas, ce n’est pas nécessaire pour être Product Owner. L’équipe de réalisation adopte une démarche pédagogique pour expliquer au Product Owner comment leurs choix techniques vont permettre d’atteindre les objectifs fixés. Il n’a pas besoin de comprendre les détails. Néanmoins, cela peut être utile dans une équipe réseau ou une équipe data par exemple.

… doit être curieux. Même sans background technique, le Product Owner s’intéresse au travail de son équipe de développement pour mieux comprendre leurs problématiques. De la même manière, il acquiert une connaissance métier avant ou au cours de la construction du produit pour être le plus pertinent possible dans ses choix.

📚 Lire notre article sur le Story Mapping

📚 Quels outils utiliser ? Voici toutes nos recommandations d'outils du Product Management, gentiment offertes par nos Product Managers.

En résumé

En résumé, un Product Owner Agile a pour missions de :

✔️ Maximiser la valeur délivrée par le(s) produits dont il est responsable ;

✔️ Dessiner la stratégie produit grâce à des feedbacks réguliers ;

✔️ Diffuser la vision produit à tout son écosystème (équipe de développement, parties prenantes …).

Enfin, le Product Owner n’est pas : …

❌ Le Chef de Projet : Chef de projet et Product Owner travaillent tous les deux avec une équipe de delivery mais les deux approches sont différentes. Un projet aura un début et une fin et le Chef de projet aura plutôt un rôle de planification calendaire, et budgétaire, là où un produit n’a pas de fin, ni de durée limitée (sauf en cas de kill) : il est développé au cours d’itérations et le Product Owner va être acteur du choix et de la priorisation des fonctionnalités développées pour le produit.

❌ Scrum Master : le rôle de Scrum Master n’a rien à voir avec celui de Product Owner mais si ce binôme de choc est en phase et collabore, c’est l’assurance d’une équipe produit qui fera des merveilles ! Le Scrum Master s’assure de l’application et du respect des valeurs et pratiques Scrum dans son équipe : ce rôle peut être assuré par une personne à part entière ou de manière tournante pour tous les membres de l’équipe Scrum sauf le Product Owner.

📚 Lire et tout savoir sur le Scrum Master

❌ Un testeur : le Product Owner est certes responsable de maximiser la valeur d’un produit à travers la bonne traduction des besoins utilisateurs en User Stories, et la bonne transmission de ces User Stories à l’équipe de développement. Néanmoins, il n’est pas responsable de ce que délivre l’équipe de développement. En effet, la phase de test doit être assurée par l’équipe de développement.

❌ Responsable de l’équipe de développement : il est courant que le Product Owner soit considéré comme un manager hiérarchique. Nombreux sont les Product Owners qui ont pu faire face à cette mauvaise compréhension du rôle : demande de validation d’absences ou de congés par exemple, attente d’approbation des choix techniques de l’équipe… C'est une énorme erreur, car le Product Owner fait partie de l'équipe. Il n'y a pas de hiérarchie sur Scrum. Par conséquent, Product Owner, Scrum Master et l'équipe de développement sont tous des pairs.

🎥  Regardez notre vidéo “Product Owner vs Chef de Projet” sur notre chaine Youtube !