Gestion de Produit Scrum : Guide Complet + Exemples
Scrum n’est pas nouveau dans le domaine de la gestion de produit. La plupart d’entre nous utilisons Scrum dans nos entreprises et essayons de naviguer entre les rôles et principes de ce cadre méthodologique pour atteindre nos objectifs.
Malheureusement, il est fréquent que les entreprises interprètent mal les principes de Scrum et les appliquent de manière incorrecte, privant ainsi les utilisateurs des nombreux bénéfices de Scrum.
Cet adorable petit guide a donc pour but de vous aider à mieux utiliser ce cadre méthodologique, en expliquant de quoi il s’agit, pourquoi il existe différents rôles dans Scrum, quelles sont les responsabilités en gestion de produit, et comment exceller dans la collaboration interdisciplinaire.
Vous voulez plus de The CPO Club ?
Inscrivez-vous gratuitement pour terminer la lecture de cet article :
Have an account? Log In
Qu’est-ce que Scrum en gestion de produit ?
Beaucoup d’entre nous aiment discuter du rôle d’un chef de produit dans la réalité des processus Scrum et de la méthodologie Agile (en d’autres termes, ce que le chef de produit fait dans une équipe Scrum). Plutôt que de simplement l’expliquer, je pense qu’il est plus facile de simplement vous montrer où se trouve le chef de produit dans l’organigramme de l’équipe.
Cependant, pour ce guide, j’aimerais aborder ce sujet dans le sens inverse et montrer comment Scrum s’intègre dans votre réalité en tant que professionnel de la gestion de produit et comment cela peut vous aider à atteindre vos objectifs de produit.
Je souhaite commencer par discuter de l’impact des principes fondamentaux du cadre Scrum sur l’efficacité de notre travail.
Le principe Scrum probablement le plus précieux pour nous est la livraison constante de valeur aux utilisateurs. Plus les gens peuvent résoudre leurs problèmes rapidement, meilleures seront les performances de votre produit. De plus, vous obtenez un accès précoce au retour d’expérience des personnes ayant utilisé la fonctionnalité dans un contexte réel.
Le deuxième avantage offert par Scrum est sa flexibilité. Si la réalité du marché évolue, vous pouvez vous y adapter rapidement en modifiant complètement votre backlog produit et en transmettant de nouvelles fonctionnalités à votre équipe dès le sprint suivant (c’est là qu’l’IA dans la planification de sprint peut être utile).
Ces deux éléments sont très difficiles (voire quasiment impossibles) à réaliser avec des cadres traditionnels comme Waterfall, où tout est figé dans les spécifications et où les utilisateurs découvrent le produit uniquement à la toute fin du cycle de vie du développement logiciel.
Exemples de succès produit grâce à l’intégration de Scrum
Ayant travaillé durant des années avec des équipes Scrum, je plaide totalement en la faveur de ce cadre Agile. Ne prenez donc pas mes propos pour parole d’évangile. Regardons plutôt des cas concrets où l’adoption de Scrum a permis à des équipes produit de réussir plus rapidement.
Microsoft Visual Studio : Le principal éditeur de code du géant de la technologie était tristement célèbre pour ses cycles répétitifs de production infernale, avec des versions remplies de bugs et des mises à jour extrêmement rares. Dès que l’équipe produit a commencé à tirer parti de Scrum, l’entreprise a constaté une nette amélioration de la stabilité produit, ainsi que des cycles de sortie bien plus fréquents — restauration de leur compétitivité sur le marché.
Spotify : L’adoption de Scrum par notre service de streaming musical préféré est l’une des plus célèbres du secteur. Spotify peinait à s’adapter et à évoluer assez vite pour relever ses défis organisationnels...jusqu’à ce que l’entreprise adopte Scrum. Ce qui distingue Spotify, c’est la création de son propre modèle de gestion de projet Scrum, regroupant des équipes agiles autonomes bénéficiant de toutes les expertises nécessaires pour expérimenter rapidement et intégrer le retour utilisateur.
ING : Le géant bancaire néerlandais a été l’une des premières institutions financières à comprendre que l’avenir de la banque serait digital. Il a aussi réalisé que ses processus de gestion de projet très traditionnels n’étaient pas adaptés au développement logiciel. L’entreprise a donc très vite adopté les méthodologies lean et Scrum et, sans surprise, elle est devenue le leader de la banque en ligne.
Rôles clés dans la gestion de produit Scrum
Si, en tant que chef de produit, vous décidez d’opter pour Scrum, voici un aperçu rapide des rôles clés de ce cadre ainsi qu’une aide pour différencier votre mission de celle du Product Owner Scrum.
Commençons par les rôles. Une équipe Scrum typique se compose des personnes suivantes :
- Scrum master : Cette personne aide l'équipe à suivre les règles Scrum et à optimiser ses processus.
- Product Owner : Il représente l'entreprise et les utilisateurs au sein de l'équipe Scrum. Les Product Owners sont responsables du backlog, fixent les objectifs de sprint et définissent les priorités des histoires.
- Équipe Scrum : Vos développeurs, designers, QA et autres spécialistes qui construisent le produit.
En ce qui concerne l’équipe Scrum, il peut y avoir de nombreux autres types de spécialistes. Le concept d’équipes pluridisciplinaires suppose que l’équipe soit autonome en matière d’accès à l’expertise professionnelle. Ainsi, par exemple, si votre produit est très axé sur l’analytique, vous pouvez avoir également un analyste de données dans l’équipe.
Chef de produit vs Product Owner : Quelle est la différence ?
La définition du product owner que j’ai donnée peut vous sembler confuse car elle ressemble beaucoup à ce que fait généralement un chef de produit.
Dans ce cas, quelle est donc la différence entre chef de produit et product owner ?
Pour comprendre la différence, examinons d’abord les responsabilités principales de chacun.
Chefs de produit
- Mener des phases de découverte produit et comprendre les besoins et les difficultés des clients.
- Définir la vision produit et l’orientation que l’équipe suivra.
- Imaginer des solutions produit capables de répondre aux besoins clients.
- Guider le processus de livraison du produit.
- Améliorer le produit par petites itérations, sur la base des retours clients et de la prise de décision basée sur les données.
- Gérer la vision et l’exécution produit à tous les niveaux de l’entreprise.
Product Owners
- Créer et maintenir le backlog produit.
- Être la source unique de vérité en matière de stratégie, de conception et de logique métier pour l’équipe Scrum.
- Prioriser les éléments du backlog et apporter de la clarté à l’équipe concernant ce qui est important.
- Définir les critères d’acceptation des fonctionnalités et accepter les résultats du sprint sur cette base.
- Débloquer les membres de l’équipe en clarifiant les exigences et en résolvant les problèmes y afférents.
- Participer aux événements Scrum et être la voix du business et des clients dans l’équipe.
Comme on peut le voir, la plupart d’entre nous accomplissent des tâches qui se retrouvent dans les deux listes. C’est tout à fait normal et courant, car beaucoup remplissent à la fois les rôles de chef de produit et de product owner.
La différence fondamentale entre ces deux fonctions est que le management produit est un métier et un ensemble de compétences, tandis que le product ownership est un rôle dans l’équipe Scrum.
Mais qu’est-ce que cela signifie ?
Cela signifie que le product owner n’a pas besoin d’être chef de produit. Dans une petite startup où il n’y a qu’un CEO et trois développeurs, le CEO prendra le rôle de product owner en fournissant aux développeurs un backlog priorisé.
La situation inverse est aussi possible. Vous pouvez être chef de produit sans être product owner. Je suis d’ailleurs un bon exemple car, dans l’une de mes anciennes équipes qui n’utilisait pas Scrum, il n’y avait donc pas de product owner. Pas de Scrum, pas de product owner dans l’équipe. Nous suivions tout de même les principes Lean et Agile.
Pour mieux illustrer la différence entre ces deux fonctions, voici un comparatif côte à côte de leurs responsabilités.
Mais alors, à quoi bon avoir un rôle spécifique au sein de l’équipe Scrum ? Ne pourraient-ils pas simplement collaborer avec des chefs de produit qui ne font pas partie de l’équipe ? J’aime beaucoup la façon dont Teresa Torres répond à cette question.
Ainsi, la véritable raison de l’existence d’un rôle produit spécifique dans l’équipe Scrum est d’apporter des connaissances et une expertise internes au produit et de renforcer encore plus la transversalité de l’équipe.
Comment le chef de produit interagit avec les équipes Scrum
En supposant que vous ayez choisi d’opter pour Scrum, il est essentiel de comprendre comment être membre de l’équipe et comment collaborer avec vos collègues. Voici un bref aperçu de ce que cela implique pour chaque événement Scrum et artefact.
- Scrum Quotidien (également appelé stand-ups) : Le travail le plus important que vous effectuez lors de ces réunions limitées dans le temps est de répondre aux questions liées au produit de votre équipe de développement et de lever les obstacles.
- Réunion de planification du Sprint : Ici, c’est à vous de fixer l'objectif du Sprint en définissant clairement vos attentes sur les fonctionnalités que vous souhaitez livrer.
- Rétrospective de Sprint : Les processus que vous utilisez pour transmettre les priorités et les exigences à l’équipe peuvent déterminer leur efficacité. Ainsi, vous pouvez utiliser cette réunion pour recueillir les retours de l’équipe et améliorer vos processus.
- Revue de Sprint : Ici, votre mission est d’accepter les fonctionnalités terminées du Sprint et de fournir à l’équipe un retour sur leur travail.
- Affinage du produit (également appelé grooming) : Vous êtes le propriétaire de cette réunion et devez profiter du temps qui vous est consacré pour discuter des priorités et des détails des user stories préparées pour l’équipe. Encouragez toujours l’équipe à remettre en question vos exigences et à trouver des « bugs produit » que vous auriez pu laisser passer.
- Backlog produit : C’est à vous de gérer le backlog du produit et de le maintenir propre et priorisé, car l’équipe construira son Sprint à partir de celui-ci.
- Backlog de Sprint : Ce n’est pas vous le propriétaire. Votre principal rôle de collaboration est de guider l’équipe à prendre les bonnes stories dans le backlog de Sprint afin de garantir qu’ils puissent atteindre l’objectif du Sprint.
En plus de cela, vous ferez d’autres types de travail produit, tels que la gestion des parties prenantes ou la découverte produit. En tant que membre de l’équipe Scrum, votre mission est de tenir l’équipe informée des besoins des parties prenantes et des utilisateurs, une fois que vous les avez clarifiés.
Par exemple, si vous avez un entretien avec un utilisateur et découvrez que l’expérience utilisateur de votre parcours de connexion est globalement confuse, il est important de partager cette information avec l’équipe afin qu’elle porte attention à cette partie lors des prochains sprints.
Meilleures pratiques pour la gestion de produit Scrum
Bien que la gestion de produit semble facile lorsque l’on regarde à travers le prisme de Scrum (et du développement Agile en général), de nombreuses erreurs sont fréquemment commises lors du travail au sein de nos équipes auto-organisées.
Voici donc quelques bonnes pratiques Scrum qui peuvent vous aider à les éviter :
- Fixer des attentes claires : La plus grande erreur que vous puissiez faire est de donner à votre équipe des priorités et exigences vagues. Le manque de clarté est une cause majeure de retards de développement et de tensions entre vous et l’équipe. Nous allons bientôt étudier en détail comment y parvenir.
- N’abusez pas de l’adaptabilité : Avoir la capacité de changer de cap est précieux, mais cela doit se faire uniquement sur votre backlog produit, pas sur le backlog du sprint. Dès que le sprint commence, ne rajoutez ni ne retirez d’histoires. Cela perturbe les plans de l’équipe et conduit à des sprints inachevés.
- Créer un environnement émotionnellement sûr : Vous êtes membre de l’équipe, pas leur chef. Évitez donc de mettre la pression sur l’équipe pour qu’elle prenne des engagements trop ambitieux ou termine plus vite. Les guides Scrum partout, y compris celui de Scrum.org insistent fortement sur le maintien de relations saines avec vos coéquipiers, car c’est l’un des piliers du travail d’équipe efficace.
Ces trois bonnes pratiques sont selon mon expérience les plus importantes. Mais si vous souhaitez encore plus de conseils sur les workflows Agiles et les bonnes pratiques Scrum pour les chefs de produit, n’hésitez pas à consulter notre guide dédié à la gestion de produit Agile.
Gérer efficacement le backlog de produit
Comme je l’ai mentionné précédemment, apporter de la clarté à votre équipe est l’une des tâches les plus cruciales d’un chef de produit. La bonne nouvelle, c’est que votre backlog produit est sans doute le meilleur outil pour y parvenir. Voici donc quelques conseils de gestion du backlog produit pour vous aider :
Les groomings : Peu importe la qualité de la rédaction de vos user stories, il y aura toujours des « bugs » et vous voudrez que l’équipe de développement les relise et vous les signale. De plus, n’étant pas développeur, il se peut que vous formuliez des exigences difficiles à mettre en œuvre. Là encore, l’équipe vous le dira durant le grooming.
Techniques de priorisation : Profitez des nombreux cadres de priorisation pour comprendre quelles fonctionnalités sont plus prioritaires que d’autres. Ma méthode préférée est le MoScoW pour sa simplicité.
Alignement sur la feuille de route et la vision : Les épopées et stories de votre backlog doivent refléter les objectifs globaux du produit et les indicateurs que vous voulez atteindre. Veillez donc à revoir régulièrement votre feuille de route avant d’ajouter des éléments au backlog.
Le signe le plus évident qu’une organisation manque de clarté, c’est lorsque vous allez dans différents services et demandez à plusieurs personnes quels sont, selon elles, les critères de réussite à atteindre pour la prochaine grande étape, et que vous commencez à entendre des versions différentes.
Aligner les parties prenantes dans Scrum
L’essence du rôle de chef de produit dans Scrum est d’être essentiellement le lien entre l’équipe auto-organisée et le monde extérieur, que ce soit les utilisateurs, les parties prenantes ou d’autres équipes.
Donc, en plus d’effectuer vos tâches habituelles de gestion des parties prenantes en tant que PM, vous devez aussi transmettre ces informations à votre équipe, et inversement. Il y aura aussi des situations où il faudra faire remonter des informations de l’équipe vers les parties prenantes.
Un bon exemple est l’apparition de défis techniques, tels que les problèmes d’intégration continue, qui peuvent influencer le calendrier ou le périmètre d’une fonctionnalité donnée. C’est un sujet qu’il faut discuter avec les parties prenantes et, soit accepter la nouvelle échéance/périmètre, soit trouver une solution alternative (par exemple : renforcer l’équipe avec davantage d’expertise sur cette question).
Il arrive également que l’équipe propose une idée intéressante de fonctionnalité ou de solution qui mérite d’être ajoutée à la feuille de route. Là encore, il faut transmettre l’information aux parties prenantes et décider si elle finit dans le plan ou non.
L’importance de la planification agile dans Scrum
Même si ce n’est pas directement un élément de Scrum, les feuilles de route agiles sont l’un des outils qui rendent Scrum possible. Après tout, quel est l’intérêt de la planification itérative si vous utilisez le modèle Waterfall pour votre produit au lieu d’une feuille de route agile ?
Dans ce cas, la stratégie produit dite « Scrum » se résumerait à découper un plan prédéfini et figé en parties de deux semaines (ou selon la durée de vos sprints) dans un modèle SDLC classique. Ainsi, pour que Scrum ait du sens pour votre équipe, il vous faut vraiment une planification agile interactive et une feuille de route capable d’évoluer avec le temps.
Pour bien adapter votre feuille de route agile aux processus Scrum de votre équipe, voici ce que je vous propose de faire :
- Liez les éléments de la feuille de route (généralement des Épics) aux user stories dans le backlog produit. Ainsi, il y aura un lien direct entre votre travail tactique (stories) et votre stratégie (feuille de route).
- Présentez votre feuille de route à votre équipe Scrum. De cette manière, elle saura où va le produit et pourra garder à l’esprit les prochaines fonctionnalités lors de la conception de l’architecture front-end ou back-end.
- Profitez d’outils spécialisés comme Jira, Monday.com et Clickup pour simplifier la gestion de vos feuilles de route et de votre backlog.
Concernant ce dernier point, ces trois outils sont ceux que j’ai utilisés en pratique. Cependant, il existe de nombreux autres logiciels de gestion produit que vous pouvez également envisager.
Les défis de la gestion produit en Scrum
Bien que Scrum soit un excellent cadre pour atteindre vos objectifs produits, l’utilisation de ce framework s’accompagne de son lot de défis, tels que :
- Votre équipe ou vos parties prenantes peuvent ne pas comprendre ce qu'est réellement Scrum. Cela peut évidemment entraîner d'importants problèmes d'adoption de Scrum, comme le refus d'utiliser certains artefacts. Je recommande d'anticiper cela en illustrant l'« état final » souhaité, à savoir comment l'équipe et le flux de travail fonctionneront une fois le cadre totalement implémenté.
- Les membres de l'équipe (y compris vous) peuvent être confus quant à votre rôle dans et en dehors de l'équipe. Chaque entreprise pour laquelle j'ai travaillé avait sa propre définition du rôle du Product Owner Scrum. Il est préférable de clarifier ce que cela signifie — et ce que cela n'est pas — pour votre équipe.
- Le périmètre des fonctionnalités sur lesquelles vous travaillez a tendance à s'élargir sans fin. Sans surprise, cela vous expose facilement au phénomène de dérive de périmètre. Les équipes Scrum doivent faire preuve de fermeté quant à ce qu'elles acceptent de prendre en charge, et savoir dire « non ».
- La feuille de route peut facilement dérailler. Avec une équipe relativement indépendante qui choisit ses sujets de travail, il est possible qu'elle construise des éléments qui n'étaient pas prévus dans votre feuille de route. Garder l'objectif final clairement en vue est primordial pour éviter cet écueil.
Bien que ces défis soient assez courants, la bonne nouvelle est qu'il ne faut généralement que quelques sprints au chef de produit pour maîtriser le processus Scrum et surmonter la grande majorité d'entre eux. Pour ceux qui souhaitent formaliser leur expertise, apprendre comment devenir Scrum Master peut donner aux leaders un véritable avantage pour guider leurs équipes à travers ce cadre.
Conclusion
Scrum est l'un des plus précieux cadeaux pour les chefs de produit. Grâce à l'équilibre entre une approche Agile à long terme et la rigueur des courtes itérations, vous pouvez éviter le chaos d'un développement Agile sans structure tout en conservant la capacité de faire évoluer votre produit en fonction des retours du marché.
Nous espérons que vous avez aimé notre guide. Si c'est le cas, n'hésitez pas à vous abonner à notre newsletter pour plus de ressources et de guides sur la gestion de produit, ainsi que pour retrouver les derniers podcasts, interviews et autres analyses d'experts et de leaders du secteur.
FAQ :
Quel est le rôle d'un Product Manager dans Scrum ?
Les chefs de produit, qui assument généralement le rôle de product owner dans l’équipe Scrum, sont responsables de fournir de la clarté à l’équipe en partageant avec elle la vision du produit, les priorités et les exigences fonctionnelles nécessaires.
En quoi Scrum diffère-t-il des autres méthodologies Agile dans la gestion de produit ?
Contrairement à Kanban ou à d’autres cadres Agile, Scrum est plus structuré et dispose de règles claires sur la façon d’organiser le travail au sein de l’équipe grâce à ses événements (stand-ups, réunions de planification, etc.) et artefacts (sprint backlog, product backlog, etc.).
Quels sont les défis courants de la gestion de produit avec Scrum ?
Le défi le plus courant est que votre équipe et vos parties prenantes interprètent mal les règles et artefacts du cadre Scrum et cherchent à les modifier avant que l’entreprise n’ait véritablement tenté de s’adapter à ce nouveau cadre.
Un Product Manager peut-il également être Product Owner ?
Oui. Product Manager est un métier. Product Owner est un rôle dans une équipe Scrum. La plupart du temps, le product owner de l’équipe est un chef de produit. Parfois, notamment dans les petites startups, le CEO peut endosser le rôle de product owner au sein de l’équipe.
