Product Owner est un rôle de Scrum par définition. Le PO est un membre de la scrum team qui est en charge de satisfaire les besoins des clients. Son objectif unique est de maximiser la valeur livrée par les équipes. Il est l’unique responsable des livrables de son équipe et est donc très motivé à bien cibler les bonnes fonctionnalités à réaliser et valider leur adéquation avec les usages des utilisateurs.
définition product owner
La définition du métier de product owner est très complexe. Il est parfois défini comme un chef de projet, un responsable métier, ou un MOA.
Ces définitions sont simplistes et trompeuses. En effet, ce rôle est riche. Il n’est défini que par son objectif qui est de maximiser la valeur livrée aux clients.
Tout le reste n’est qu’outils et pratiques que certains PO adopteront et d’autres rejetteront.
Contexte de travail du PO ?
Le product owner travaille au sein d’une équipe scrum. Cela signifie qu’il collabore au quotidien avec les développeurs (maximum 8 par équipe) et le scrum master pour mettre en œuvre le produit. Les réalisations sont échelonnées sur des “sprints” de 2 à 4 semaines. La mise en place de ces itérations ou sprints permet de livrer régulièrement et de vérifier l’adéquation des réalisations avec l’environnement, les besoins client, les technologies,…
Quel est le rôle du Product Owner ?
Le rôle du product owner est d’identifier les besoins réels des clients (utilisateurs finaux) et de les formaliser sous forme de user stories. Ensuite, le PO priorise les user stories au sein du backlog.
A chaque sprint, il va permettre à l’équipe de comprendre les US les plus prioritaires. Il va répondre à leurs questions pendant la phase de réalisation. Finalement, il valide les livrables et décide de la date de mise en production.
Quels sont les challenges et compétences du product owner ?
Cela peut sembler évident de retranscrire les besoins des clients et de les prioriser puis suivre la réalisation. En vrai, le product owner rencontre un grand nombre de difficultés à chaque étape. Seules ses compétences professionnelles l’aident à remplir sa mission.
Recueil des besoins :
D’abord il faut identifier toutes les catégories de clients, leurs besoins, leurs usages,… Il faut souvent voir large et ne pas oublier certains usagers.
Souvent, les clients formulent leurs besoins sous forme de solution : “je veux une voiture” au lieu de dire “je veux me déplacer”. Ou alors “je veux un rouge à lèvre” au lieu de “j’ai besoin d’apporter une touche d’originalité à mon maquillage”.
Or le product owner est un expert de son domaine. Il doit apprendre à identifier le besoin derrière la demande. C’est lui qui proposera la meilleure solution.
Une partie des demandes vient de manière détournée : remarques anodines, difficultés de manipulation, ou critiques,…
Le PO est à l’affût de ces retours qui vont le mettre sur la piste des besoins les plus prioritaires de ses clients.
Priorisation des besoins par le PO
La priorisation n’est pas une mince affaire. Car suite au recueil des besoins, la liste est souvent très longue. Chaque utilisateur a des priorités différentes. Il faut donc satisfaire un maximum de personnes sans en décevoir trop.
Le product owner met donc en œuvre ses meilleures compétences de profiler pour identifier quelle fonctionnalité profite à quels personas. Il va noter chaque user story afin de pouvoir prioriser son backlog de façon factuelle.
L’effort de réalisation entre souvent en compte à cette étape. Le product owner fait donc régulièrement appel à son équipe pour y voir plus clair.
A cette étape les enjeux de l’entreprise entre en compte également. Le product owner peut éliminer une user story qui ne correspond pas à la vision de l’entreprise dont il fait partie.
Expliquer le besoin à l’équipe
Lors de la cérémonie de sprint planning, le product owner expose la user story la plus prioritaire à l’équipe. Il donne toutes les informations nécessaires à sa compréhension et répond aux questions de l’équipe.
Ainsi, ce représentant des clients communique à l’équipe les réelles motivations pour la mise œuvre de ce besoin.
Le PO s’assure ainsi que le besoin est bien compris. L’équipe valide par la suite sa capacité à le réaliser, ou le besoin de découper le sujet s’il est trop important.
S’ils ont encore de la capacité dans le sprint, le product owner exposera 1, 2, 3 autres US jusqu’à ce que l’équipe confirme avoir atteint sa capacité du sprint.
Accompagner la réalisation
Tout au long de l’itération, le PO est en contact avec les développeurs pour répondre à leurs questions et effectuer les arbitrages nécessaires.
Bien entendu, ces activités se font en parallèle de son travail sur le backlog. A aucun moment l’une des activités ne prend le pas sur la seconde.
Valider les réalisations
A la fin de la réalisation de chaque US, le PO teste et valide les livrables.
Décider de la mise en production
Le product owner décide de la date de mise en production des réalisation. Pour cela il doit prendre en compte l’écosystème de l’entreprises, les contraintes des autres équipes (notamment techniques) et la concurrence.
En conclusion
Le product owner est à la fois ethnologue, communiquant, statisticien et stratège. Il doit être minutieux, calme et avoir beaucoup de recul.
Sa proximité avec l’équipe de développement nécessite également une bonne compréhension des développeurs et de leur métier.
Le product owner est donc un professionnel sénior et qualifié.