Le Product Owner, pilier de l’équipe Scrum : rôle et responsabilités clés

Imaginez un peu : vous venez d’acheter une maison, et en tant que nouveau propriétaire, il vous revient de décider à quoi celle-ci ressemblera à long terme. Comment la rénover, la décorer et l’entretenir pour tirer le maximum de cet investissement conséquent ? Dans un premier temps, il vous faudra communiquer vos attentes aux ouvriers et au chef de chantier, puis tout coordonner... sans oublier les personnes avec lesquelles vous vivez, qui participent elles aussi à la création de votre petit nid douillet, tout cela en ne perdant de vue ni vos finances ni vos objectifs à long terme. Pas évident, n’est-ce pas ?

Il suffit de remplacer la maison par un produit, et vous avez le rôle du Product Owner, qui lui aussi s’attèle à un chantier de longue haleine. En effet, ce dernier travaille main dans la main avec les parties prenantes (les ouvriers et vos proches, donc, pour reprendre notre exemple) dans le but d’obtenir le meilleur produit possible pour le compte des utilisateurs finaux. Il doit donc déterminer quelles sont les fonctionnalités qui sont les plus utiles, puis les transformer en tâches concrètes, sur lesquelles travailleront les concernés.

Quel est le rôle du Product Owner ?

Le Product Owner est indispensable aux équipes Scrum soucieuses de proposer un produit exceptionnel aux utilisateurs finaux. Dans cette optique, il se fait une idée du produit et de son fonctionnement, puis détermine les fonctionnalités qui lui sont propres et enfin les ajoute au backlog produit sous forme de tâches à réaliser par l’équipe Scrum. Non seulement responsable du produit fini, le Product Owner est chargé de faire le lien entre les différents acteurs de l’entreprise, les membres de l’équipe Scrum et les utilisateurs finaux.

Le Product Owner endosse l’un des trois rôles piliers de l’équipe Scrum classique :

• Product owner : travaille en collaboration avec les parties prenantes, les utilisateurs finaux et l’équipe Scrum dans le but de créer un produit final répondant aux exigences des utilisateurs, dans la continuité des objectifs commerciaux.

• Scrum Master : est à la tête de l’équipe de développement, dont il aide à préparer et exécuter les sprints. Cela passe également par l’amélioration continue des processus internes.

• Équipe de développement : travaille à la création des livrables à produire pour chaque sprint. Les développeurs sont les éléments pivots de l’équipe Scrum, puisqu’ils ont pour mission de réaliser les tâches du backlog produit, qui donneront de nouvelles fonctionnalités produit.

Product Owner ou Scrum Master ?

Aussi différents que complémentaires, le Product Owner et le Scrum Master sont l’un et l’autre essentiels à toute équipe Scrum performante. Le Scrum Master est à la tête des processus internes nécessaires aux équipes Scrum pour effectuer leur travail, des processus qu’il améliore constamment. Il aide l’équipe à organiser ses sprints et à les mettre en œuvre efficacement, permettant ainsi aux développeurs de se concentrer sur leur cœur de métier plutôt que sur la logistique qui l’entoure. Le Scrum Master s’occupe de planifier les réunions, notamment les réunions debout quotidiennes, ainsi que les rétrospectives de sprint. En tant que chef d’équipe, il ouvre le chemin aux développeurs en balayant les obstacles sur leur chemin et s’assure que tous travaillent dans le respect des principes de la méthode Scrum.

De son côté et contrairement au Scrum Master, le Product Owner est un peu éloigné de l’œil du cyclone. Il se concentre moins sur les processus de l’équipe que sur le produit en lui-même ; ou plutôt, il fait le maximum pour proposer le meilleur produit possible aux utilisateurs finaux. À ce titre, il recueille le feedback des parties prenantes et des utilisateurs finaux, sur lequel il s’appuie pour imaginer des fonctionnalités spécifiques au produit. Celles-ci se traduisent par de nouvelles tâches de backlog produit, sur lesquelles travaillera l’équipe Scrum.

Product Owner ou chef de projet ?

Si les rôles de Product Owner et de chef de projet peuvent sembler similaires, il faut savoir qu’ils diffèrent sur certains points essentiels. Le rôle de chef de projet ne fait pas partie des indispensables de l’équipe Scrum. En général, les principales préoccupations d’un chef de projet tourneront autour de la gestion des ressources et de la production des livrables liés à un projet. Si l’on voit le projet comme un ensemble de tâches à accomplir pour atteindre un objectif précis, on peut donc dire que le chef de projet est là pour aider les équipes à planifier, gérer et réaliser ces tâches, la finalité étant de remplir dans les temps l’objectif fixé.

Ses responsabilités ne sont donc pas les mêmes que celles du Product Owner, qui cherche absolument à obtenir le produit idéal pour les utilisateurs finaux et n’a pas pour vocation à coordonner le travail au quotidien. Au sein d’une équipe Scrum, le Product Owner et le Scrum Master se partagent les activités liées à la gestion de projet. Par exemple, le Product Owner va créer les tâches du backlog produit, tandis que le Scrum Master veillera pour sa part à la bonne attribution de ces mêmes tâches, sans oublier l’allocation des ressources et la gestion des disponibilités de travail de l’équipe.

Product Owner ou chef de produit ?

On mélange souvent les rôles de Product Manager et de chef de produit. Pourtant, au sein d’une équipe Scrum, le Product Owner aura souvent tendance à endosser un rôle bien précis là où le chef de produit aura un rôle plus large, qui ne rentrera pas nécessairement dans le cadre d’une structure Agile.

Cependant, certaines équipes comptent à la fois un Product Owner et un chef de projet, auquel cas leurs responsabilités diffèrent sur les points suivants :

• Le chef de produit agit à un niveau plus global, dans une optique stratégique. Il s’appuie sur les objectifs de l’entreprise et prend en compte les forces du marché pour établir la vision produit.

• Le Product Owner adopte pour sa part une approche plus tactique. Il transforme la stratégie élaborée par le chef de produit en tâches concrètes et collabore avec les partenaires transverses, ce dans le but de répondre à ces exigences.

Toutefois, il arrive souvent que le Product Owner d’une équipe Agile remplisse également les fonctions de chef de produit, combinant ainsi l’élaboration de stratégies globales et les activités tactiques visant à transcrire les fonctionnalités en tâches concrètes.

Modalités de collaboration entre le Product Owner et son équipe Scrum

Le Product Owner travaille en étroite collaboration avec les autres membres de l’équipe Scrum. Il aide cette dernière à faire le rapprochement entre les tâches du backlog et la vision globale du produit, et fait office d’intermédiaire entre l’équipe Scrum et le reste de l’entreprise. Grâce à lui, l’équipe n’a pas à s’occuper des communications auprès des partenaires interfonctionnels et peut se focaliser sur ses tâches. Le Product Owner s’appuie également sur ses collègues de l’équipe Scrum pour acquérir des connaissances pointues au sujet du produit en cours de développement. Par exemple, l’équipe pourra lui expliquer comment sont créées certaines fonctionnalités inhérentes au produit, quels sont les types de changements envisageables ou encore les relations de dépendance entre les tâches.

Pour ce faire, le Product Owner peut organiser des réunions quotidiennes ou hebdomadaires avec son équipe :

• Les réunions debout quotidiennes : le Product Owner assiste régulièrement aux réunions quotidiennes organisées avec l’équipe Scrum. Elles sont l’occasion pour lui d’obtenir directement des informations au sujet de la progression de l’équipe et des problèmes éventuels. Ces réunions l’aident donc à remplir son rôle d’intermédiaire entre l’équipe de développement produit et les autres acteurs de l’entreprise, qu’il peut aisément informer de la situation.

• Les réunions de « backlog refinement » ou entretien du backlog : en général, le Product Owner se réunit avec l’équipe Scrum au moins une fois par semaine dans le but d’assurer la gestion du backlog et de préparer les tâches du prochain sprint à l’avance. Lorsqu’il s’agit de s’atteler aux tâches du backlog produit, la balle est dans le camp des membres de l’équipe de développement, qui sont les vrais experts dans ce domaine. Le Product owner écoute donc attentivement leurs conseils afin de déterminer les améliorations et ajouts de fonctionnalités réalisables par l’équipe à chaque sprint.

• Les réunions d’analyse de sprint : le Product Owner peut aussi organiser une réunion d’analyse de sprint à chaque fin de sprint. Au cours de ce type de réunion, l’équipe Scrum présente le travail réalisé, en général par le biais d’une démonstration produit qui permettra aux acteurs interfonctionnels de se faire une idée précise de chaque livrable et d’en comprendre l’intérêt.

Les cinq responsabilités clés du Product Owner

Comme nous l’avons vu, le Product Owner fait donc le lien entre l’équipe Scrum et les autres parties prenantes, tout en s’assurant que les besoins des utilisateurs finaux sont bien pris en compte, ce afin que chacun comprenne la finalité du produit et la raison derrière sa création. Mais s’il porte souvent plusieurs casquettes, son rôle se limite aux cinq grandes responsabilités suivantes.

1. Définir les objectifs du produit

Le Product Owner définit les objectifs de chaque produit, puis les fonctionnalités qui permettront à un produit donné d’atteindre ces objectifs.

Pour établir des objectifs, le Product Owner doit connaître les attentes des utilisateurs vis-à-vis du produit et garder en tête les problèmes auxquels ils sont régulièrement confrontés. La recherche utilisateur prend donc une place majeure dans son travail. Un exemple : imaginons que vous ayez pour mission d’apporter des améliorations à une application de calendrier. Dans ce cas, pour déterminer quel sera votre objectif, vous analyserez les interactions des utilisateurs avec l’application existante, avant de leur demander quels sont les éléments de l’application qui posent problème et les pistes d’amélioration possibles.

Outre le fait de s’appuyer sur le feedback des utilisateurs pour fixer des objectifs, le Product owner doit également s’assurer que toutes les nouvelles fonctionnalités s’insèrent dans le cadre des objectifs commerciaux en général. Reprenons notre exemple précédent : si les utilisateurs souhaitent pouvoir partager des calendriers avec des tiers extérieurs à leur entreprise et que vous vous êtes donné pour objectif général d’améliorer la sécurité et la confidentialité de l’application, une telle fonctionnalité pourrait aller à l’encontre de votre objectif d’entreprise. En tant que Product Owner, il vous revient également d’identifier les demandes utilisateur à concrétiser ou non.

2. Décider des fonctionnalités produit et remplir le backlog en conséquence

Une fois les objectifs définis, le Product Owner doit œuvrer à les concrétiser. Pour ce faire, il concrétise les fonctionnalités produit et les tâches de backlog sur lesquelles travaille l’équipe Scrum. Cette dernière peut ainsi se concentrer pleinement sur chaque élément du backlog dans ses moindres détails, alors que le Product Owner veille à ce que ces mêmes éléments répondent aux objectifs de l’entreprise et aux besoins des utilisateurs.

Revenons une fois encore à notre exemple d’application de calendrier : ici, le Product Owner pourra par exemple imaginer une fonctionnalité produit permettant de connaître les horaires de travail habituels de chacun des membres d’une équipe. Le Product Owner s’organisera ensuite avec l’équipe Scrum de façon à répartir la création de cette fonctionnalité en plusieurs petites tâches concrètes, qui seront ajoutées au backlog produit (développement du design en front-end, création de l’interface utilisateur permettant de renseigner les heures habituelles, etc.).

3. Créer des récits utilisateurs (user stories)

Le Product Owner est aussi à l’origine des récits utilisateurs (user stories) qui aideront les membres de l’équipe à saisir le contexte entourant la création de chaque fonctionnalité produit. En gestion de projet Agile, la « user story » explique l’utilité d’une fonctionnalité produit de manière non technique, selon le point de vue de l’utilisateur. Ce type de scénario d’utilisation a pour but de clarifier le ou les objectifs derrière une fonctionnalité donnée, afin que l’équipe de développement se fasse une idée précise de ce qu’elle est en train de concevoir, des raisons qui expliquent cette conception et de sa valeur ajoutée.

Les scénarios d’utilisation sont généralement rédigés en une seule phrase, en adoptant la structure ci-après :

« En tant que [persona], je souhaiterais [objectif du logiciel], afin de [résultat]. »

Revenons là aussi à notre exemple de calendrier, pour lequel le Product Owner pourrait souhaiter rédiger un scénario d’utilisation précisant les objectifs de la fonctionnalité :

« En tant que manager d’une équipe à distance, je souhaiterais connaître les horaires de travail des membres de mon équipe, afin d’organiser les réunions à des heures qui conviennent au plus grand nombre. »

4. Hiérarchiser et gérer les tâches du backlog produit

En plus des fonctionnalités produit, le Product Owner a la responsabilité de l’entretien du backlog : il gère le backlog produit et en hiérarchise les tâches en fonction des besoins de l’entreprise, des objectifs du produit et bien sûr des exigences des utilisateurs. Ayant un aperçu général du produit et de sa relation avec les objectifs globaux de l’entreprise, il est à même d’indiquer à l’équipe Scrum sur quelles tâches se concentrer en premier. Par exemple, si l’entreprise a mis en place une initiative générale visant à améliorer la confidentialité utilisateur, il peut donner la priorité aux tâches liées à la sécurité.

Au-delà de la hiérarchisation des tâches du backlog produit, le Product Owner veille à ce que les parties prenantes en aient une bonne visibilité et une compréhension poussée. Ainsi, ces dernières comprennent mieux comment l’équipe Scrum intègre leur feedback et en tire de nouvelles fonctionnalités produit, pourquoi elle fait passer certaines tâches avant d’autres et quel est le délai attendu à la suite d’une nouvelle demande de fonctionnalité.

5. Superviser le développement produit à chaque étape

La plupart du temps, lorsqu’une équipe développe un nouveau produit ou ajoute une nouvelle fonctionnalité, elle suit un processus prédéfini afin de s’assurer que le produit sera conçu, testé et mis en œuvre correctement. Connue sous le nom de processus de développement produit, cette pratique repose sur un plan en six étapes, allant du concept d’origine au lancement du produit final sur le marché.

Le Product Owner se coordonne avec les parties prenantes essentielles dans le but de gérer la conception du produit à travers chaque étape de son processus de développement :

1. Idéation : phase de réflexion, utile pour trouver des concepts produit en se basant sur les besoins client et les études de marché.

2. Définition du produit : cadrage de fonctionnalité, rédaction de la proposition de valeur et identification des indicateurs de réussite.

3. Prototypage : création d’une preuve de concept, une version du produit qui permet d’établir la faisabilité des fonctionnalités et d’élaborer une stratégie de développement.

4. Conception initiale : création d’une première version du produit, utile pour recueillir les premiers retours des parties prenantes et des utilisateurs finaux.

5. Validation et tests : phase préalable au lancement sur le marché, utile pour s’assurer que chaque élément du produit fonctionne efficacement avant sa diffusion auprès du public.

6. Commercialisation : lancement et intégration du produit fini.

En suivant un processus comme celui-ci, l’équipe Scrum met toutes les chances de son côté pour concevoir le meilleur produit possible, tout en minimisant les risques.

En quoi le rôle du Product Owner est-il essentiel ?

Le Product Owner participe grandement aux performances d’une équipe Scrum, en l’aidant à :

Définir la vision produit

L’ajout de nouvelles fonctionnalités produit et l’élaboration d’une feuille de route requièrent une planification minutieuse. Le Product Owner doit non seulement s’assurer que le produit (et les améliorations qui lui sont apportées) offre la meilleure expérience possible aux utilisateurs finaux, mais aussi que chacune des nouvelles fonctionnalités rentre bien dans le cadre des objectifs généraux de l’entreprise. Le simple fait d’indiquer clairement à quoi sert chaque élément du backlog aide grandement l’équipe Scrum à consacrer son temps aux tâches les plus utiles.

Accorder la priorité aux demandes des parties prenantes et des utilisateurs finaux

Si les parties prenantes sont bien souvent persuadées de l’absolue priorité de leurs projets, le Product Owner reste le mieux placé pour décider des tâches sur lesquelles l’équipe Scrum travaillera en priorité, ayant toutes les informations de contexte pour en juger. Au fait des priorités de l’entreprise, il sait l’importance de chacune des initiatives et peut identifier les tâches qui y participent. Il peut donc donner la priorité au feedback des parties prenantes qui sera le plus pertinent et aider l’équipe Scrum à se concentrer sur le travail le plus important. Sans son Product Owner, l’équipe Scrum aurait tendance à suivre les directives des équipes interfonctionnelles pour décider des tâches prioritaires.

Par ailleurs, le Product Owner fait appel à des tests d’utilisabilité pour recueillir les avis des utilisateurs finaux, restant ainsi à l’écoute de leurs besoins : un autre outil qui lui permet de décider au mieux des tâches à réaliser en priorité pour résoudre les difficultés rencontrées par les utilisateurs.

Veiller au respect des directives au cours du développement produit

Enfin, le Product Owner sert de guide à son équipe Scrum et aux parties prenantes tout au long du processus de développement produit, généralement divisé en six étapes, comme nous l’avons vu précédemment (même si chaque entreprise aura sa propre version). Ce processus prédéfini accompagne les équipes dans leurs lancements de produits, en limitant les risques au maximum. Par exemple, l’équipe devrait commencer par créer un prototype qui servira à tester le concept initial, puis réaliser des tests en front-end afin de repérer tout problème de développement ou risque, pour finir par procéder à des tests d’utilisabilité dans le but de s’assurer que le produit fini répond aux attentes et aux exigences des utilisateurs finaux.

En général, ce processus est établi par les responsables de l’équipe produit et le Product Owner n’en est donc pas à l’origine. Toutefois, ce dernier doit veiller à ce que l’équipe en respecte le déroulement et assurer la coordination avec les parties prenantes.

Prenez la situation en main

Le Product Owner est un élément essentiel à toute équipe Scrum qui se respecte. Détenteur d’une vision produit globale, qu’il cultive constamment, il aide l’équipe à la concrétiser et fait comprendre à chacun en quoi les nouvelles fonctionnalités produit représentent un intérêt et dans quel but elles sont créées.

Pour être performant, un Product Owner doit pouvoir collaborer au quotidien aussi bien avec ses collègues de l’équipe Scrum qu’avec toutes les parties prenantes concernées. À ce titre, l’utilisation d’un outil de gestion de projet est un bon moyen de rationaliser les activités, planifier les sprints, réaliser les tâches et communiquer, le tout au même endroit.