Le Product Owner est un acteur clé dans l’organisation d’une équipe Scrum et dans la réussite d’un projet Agile. Il est le responsable du produit. Son rôle principal est de définir et de porter la vision du produit dont il a la charge, de déterminer dans quel ordre le produit sera construit, en priorisant avant tout les fonctionnalités ayant une plus forte valeur pour l’utilisateur et un ROI important pour l’entreprise.
Il travaille en coordination étroite avec son équipe (Développeurs, Testeurs, ScrumMaster, UX Designers, Exploitants) et fait le lien avec toutes les parties prenantes impliquées dans le projet.
Son objectif premier est de faire adhérer les personnes aux objectifs du projet, partager une vision unifiée du produit et insuffler une dynamique.
Sa principale difficulté ? L’équipe de développement, les stakeholders ou encore les partenaires ont tous des besoins et des objectifs différents. Le secret du Product Owner pour créer un produit à forte valeur ajoutée ? Savoir dire « non » quand c’est nécessaire pour toujours garantir un produit centré sur les besoins des utilisateurs et le ROI.
« Non, nous ne pourrons pas tout livrer d’un coup »
Afin que le coût de revient du projet soit le plus faible possible, l’équipe doit montrer une première version du produit aux utilisateurs le plus tôt possible (« MVP« ). Développer les fonctionnalités primordiales et soumettre une première version du produit aux utilisateurs permettra à l’équipe de récolter rapidement des feedbacks et des axes d’amélioration de la part des utilisateurs. Le Product Owner pourra alors s’assurer de la pertinence du produit et de la présence d’un marché réceptif. Il adaptera ensuite la trajectoire du produit pour s’assurer qu’il répond réellement aux besoins et par conséquent maximiser le ROI. Mais cela implique d’assumer la sortie d’un produit qui n’est pas encore complètement terminé.
« Non, toutes ces demandes ne tiendront pas dans un seul sprint »
Le Product Owner insuffle une dynamique au sein de son équipe pour créer un maximum de valeur en un minimum de temps. Malgré tout, son objectif est de s’assurer que l’équipe reste investie et motivée sur toute la durée du projet. Que tous les membres restent occupés sans pour autant être surchargés. En résumé : il doit privilégier l’endurance de l’équipe et non la vitesse maximale envisageable. Le Product Owner doit donc savoir dire « non » quand les exigences des parties prenantes sont décorrelées de la capacité de l’équipe.
« Non, nous ne pouvons pas modifier le périmètre du sprint en cours »
La rédaction des User Stories à développer doit être réalisée en amont du début du sprint. Une fois qu’une User Story est découpée, partagée et intégrée dans un sprint, il n’est plus possible de modifier le périmètre de la fonctionnalité souhaitée. En effet, des perturbations incessantes nuiraient au bon déroulement des développements, à la « santé » de l’équipe et à la vision du produit. C’est pourquoi le PO doit savoir dire « non » lorsqu’on lui demande de modifier le périmètre ou le contenu du sprint en cours. Les adaptations nécessaires pourront en revanche intervenir dès le début du sprint suivant.
« Non, cette fonctionnalité ne pourra être déployée en production telle quelle »
Le Product Owner a la capacité de refuser le déploiement d’une fonctionnalité développée par son équipe à un instant T, s’il estime qu’elle apporte un bug bloquant ou une dégradation de la qualité du produit. En tant que « responsable du produit », le PO doit s’assurer que l’expérience utilisateur reste optimale.
Cette liste (non exhaustive) peut sembler dresser un tableau assez noir du rôle du Product Owner. Malgré tout, sa posture est essentielle pour la réussite du projet. Sans la capacité de dire « non », le Product Owner entraînerait le développement d’un produit qui n’a plus de sens ou qui ne correspond plus à la vision partagée. Enfin, la posture du Product Owner ne doit pas faire oublier que la gestion d’un projet Scrum est un sport collectif !
Le PO doit savoir s’appuyer sur son équipe et tous les interlocuteurs investis.
S’il est souvent amené à prendre des décisions, le Product Owner ne décide jamais complètement seul.
UPDATE : Ce sujet a fait l’objet d’un des #Meetup de @SchoolOfPO. Pour en savoir plus, rendez-vous sur la bibliothèque dédiée.