Nous avons débuté cette série par un premier article qui définissait la culture produit en comparaison à la culture projet bien implantée dans l’industrie logicielle depuis de nombreuses décennies. Cet article a été l’occasion de vous montrer l’importance d’avoir une culture produit lorsque l’on travaille avec une approche agile, et particulièrement avec Scrum. Dans ce framework, la place importante donnée au produit est principalement matérialisée par le rôle de Product Owner que Scrum introduit. Le deuxième article de notre série a d’ailleurs été l’occasion d’aborder un peu plus en détail les activités qu’un Product Owner réalise au quotidien. Ces nombreuses activités, qu’elles portent sur les aspects stratégiques du produit ou les aspects plus opérationnels, montrent la richesse et l’importance du rôle de Product Owner. Dans ce dernier article, nous souhaitons revenir sur des aspects très opérationnels pour vous aider dans votre rôle de Product Owner, en vous parlant de son outillage au quotidien. Il serait compliqué d’aborder tous les outils d’un Product Owner en un seul article. Comme le définit le Scrum Guide : « Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. » Ceci peut se matérialiser de plusieurs manières différentes, mais une tâche qui est toujours centrale à la bonne exécution de ce rôle est la gestion du Product Backlog. C’est pourquoi nous allons nous concentrer ici sur les outils et pratiques autour de la gestion du Product Backlog.
Le Product Backlog : un artefact vivant, unique source du travail à réaliser
Un Product Backlog est une liste des nouvelles fonctionnalités, des modifications des fonctionnalités existantes, des corrections de bugs, des changements d'infrastructure ou d'autres activités qu'une équipe peut livrer afin d'atteindre un résultat spécifique.
En tant que Product Owner, nous pouvons considérer le Product Backlog comme notre route actuelle. Cette route représente notre meilleure compréhension à l’instant T de comment nous allons atteindre notre destination finale. Ceci est une image importante à retenir, car peu importe la vélocité (si valorisé par certains), si la route ne pointe pas vers la bonne destination finale, nous arriverons plus vite au mauvais endroit.
Un Product Backlog bien défini, ordonné et estimé nous fournit une direction et toutes les informations nécessaires pour la planification du travail de la Scrum Team. Cependant, pour que ça fonctionne il est impératif que le Product Backlog soit la seule source de travail pour l’équipe.
Supposons que nous disposons d'un Product Backlog pour les fonctionnalités à développer, d'un Bug Backlog pour les problèmes rencontrés, d'un Backlog technique pour l'infrastructure et l'architecture, et que des travaux non planifiés sont réalisés pendant le sprint. Cette situation est assez fréquente dans beaucoup d’entreprises, et c’est facile à remarquer que nous perdons toute transparence de l’avancement du développement, ainsi que du travail qui reste à réaliser pour atteindre nos objectifs.
Pour faciliter l’absorption de ce concept, retenez la logique suivante :
Un produit --> Un Product Owner --> Un Product Backlog
qui contiendra tout le travail pour la Scrum Team.
Cela signifie que rien n'est fait qui ne figure pas dans le Product Backlog. En parallèle, ce n’est pas parce que quelque chose figure dans le Product Backlog que ça va forcément être développé.
Le Product Owner a pour fonction non seulement la création des éléments du Product Backlog, mais aussi leur ordonnancement en fonction de leur priorité pour atteindre l’Objectif de Produit.
L’Objectif de Produit
L’Objectif de Produit, introduit lors de la version de novembre 2020 du Scrum Guide, est la représentation d’une étape à accomplir pour avancer en direction de la Vision produit (si vous ne savez pas de quoi s’agit la vision produit, allez lire le 2e article de cette série. Nous pouvons dire que c’est un état futur du produit qui peut servir de cible pour aider dans la planification par la Scrum Team, dans la construction de la Roadmap Produit, par exemple.
La Scrum Team doit forcément atteindre ou abandonner un Objectif de Produit avant de passer à un autre. L’importance de faire cela est de permettre à l’équipe de se concentrer à part entière sur un seul Objectif de Produit à la fois, et ainsi d’être plus efficace dans l’aboutissement de cet objectif.
Pour définir un Objectif de Produit nous pouvons faire appel au Product Canvas, outil décrit ci-dessous :
Ayant tout d’abord la clarté sur la vision du produit vers laquelle nous souhaitons avancer, nous remplissons le template ci-dessus dans l’ordre suivant :
Users (utilisateurs) : Définir qui sont nos utilisateurs est très important. L’utilisation d’une approche agile pour construire notre produit implique de travailler à proximité des utilisateurs de ce produit pour avoir des retours réguliers de leur part. Définir donc qui seront les utilisateurs nous permet d’avoir une meilleure compréhension de leurs besoins, et ainsi de proposer une solution qui s’aligne mieux à leur réalité. D’autres outils (que nous ne détaillerons pas dans cet article) peuvent assister à cette définition des profils utilisateurs, comme l’Empathy Map et les Personae (si ça vous intéresse de connaitre d’avantage ces outils, entre autres, n’hesitez pas à vous inscrire à la prochaine formation « Devenir Product Owner » d’Invivoo.
Stakeholders (parties prenantes) : Ici nous allons inclure toutes les parties prenantes qui ne sont pas les utilisateurs, comme les différentes équipes qui seront impactés par les résultats de ce qu’on développe, des fournisseurs desquels dépendent notre développement, des régulateurs ou bien encore les sponsors du développement.
Needs (besoins) : Sachant qui sont nos utilisateurs finaux, il faut que nous puissions décrire quels sont leurs attentes par rapport au produit. Ceci est le « coeur » de l’objectif produit, où nous décrirons quels problèmes nous allons résoudre. Il est important de faire attention ici à limiter les besoins auxquels nous voulons répondre avec ce produit, afin de ne pas perdre de vue les besoins les plus importants et se disperser vers des objectifs secondaires.
(Métriques) : Ici nous allons définir comment nous saurons que l’objectif a été atteint, ou aussi nous pouvons l’interpréter comme « Quelle sera la valeur ajoutée au produit si nous atteignons cet objectif ?» ou bien « Quels seront les impacts business pour les utilisateurs si nous atteignons cet objectif ? ». De la même façon que pour les besoins, il est important de limiter le nombre de métriques, afin de ne pas perdre de vue les principales. Cette partie peut avoir un lien avec les critères d’acceptance pour les User Stories, que nous aborderons plus tard dans cet article.
Product Goal (Objectif Produit) : Finalement dans cette case nous allons décrire l’objectif que nous souhaitons atteindre et qui justifie les développements qui en découleront. Il est important de renforcer que chaque Objectif Produit doit être la seule source de travail pour la Scrum team, et que l’équipe ne doit traiter qu’un seul Objectif Produit à la fois. Donc il est très important que l’objectif soit synthétique, pour permettre à l’équipe d’avancer vers les besoins principaux des utilisateurs.
Il y a différentes variations du template de Product Goal Canvas, mais ce qui est important c’est de s’assurer que nous puissions répondre aux questions suivantes :
Quels segments des utilisateurs desservons-nous ?
Quel est le problème que nous voulons résoudre ?
À quoi ressemble notre solution et comment se différencie-t-elle de ce qui existe aujourd’hui ?
Comment le produit crée-t-il de la valeur pour notre propre entreprise ?
Ayant la réponse à ces questions, nous pouvons venir décrire l’objectif produit plus aisément. Il existe plusieurs façons de structurer l’objectif de produit, l’un des plus simples étant :
Pour (public concerné par le produit) avec (Problème/formulation des besoins clés) nous livrons (Solution). Grâce à cela, nous atteignons la (Business value).
La façon la plus utilisée d’écrire les items du Product Backlog ce sont les fameuses User Stories, que nous allons décrire plus en détail ci-dessous.
La User Story
Une User Story est la plus petite unité de travail dans un cadre agile qui apporte une valeur directe ou indirecte aux utilisateurs du produit. Il s'agit d'une explication informelle et générale d’un objectif final (et non d'une fonctionnalité), exprimé du point de vue de l'utilisateur du produit.
L'objectif principal de cet élément est de placer les utilisateurs finaux au centre de la conversation et d’en découler les fonctionnalités du produit à partir de leur point de vue. Ainsi, la Scrum Team peut avoir une meilleure compréhension de ce qu'ils construisent, pour qui et pourquoi.
Chaque User Story doit représenter une valeur ajoutée pour l’utilisateur. En quelques mots, nous pouvons dire qu’une User Story est une description fonctionnelle pour spécifier le développement d’une fonctionnalité en exprimant :
Le besoin qu’elle adresse,
La valeur qu’elle apporte
À quel(s) utilisateur(s) elle s’adresse
Elle doit être de la plus petite granularité possible de façon à pouvoir la livrer le plus rapidement possible. En Scrum, elle doit tenir dans un sprint. Elle doit être acceptée par les utilisateurs (dans le sens où elle apporte de la valeur) et par l’équipe Scrum (dans le sens où elle est suffisamment claire et petite pour être réalisée dans un sprint).
Si la fonctionnalité à développer est complexe et requiert plus qu’un sprint de développement, elle sera décrite par un Epic, qui lui-même sera décomposé en plusieurs User Stories.
Pour faciliter la compréhension, voici un exemple :
Supposons que nous voulons créer une application de rencontres. L’organisation d’une des fonctionnalités nécessaires par Epic et User Stories pourrait être :
Ainsi, les Epics nous fournissent une vue de haut niveau de nos objectifs et de la manière dont nous les atteignons. Cela nous aide également lors du processus de hiérarchisation des priorités, car nous pouvons vérifier quels Epics requièrent le plus urgemment notre attention et, par conséquent, quelles Stories doivent être priorisées.
Nous pouvons résumer les différences entre un Epic et une User Story par le tableau suivant :
Mais comment faisons-nous pour créer une bonne User Story ?
Il y a deux règles très utilisées : la règle des 3C et INVEST
3C
Selon la règle des 3C, une bonne User Story doit être :
Une Carte – Les stories sont écrites sur des cartes, ce qui assure qu’elles soient suffisamment petites pour être concise (car il s’agit de la plus petite unité de travail qui va apporter de la valeur). Les cartes peuvent être annotées avec des estimations, des commentaires, etc… ;
Une Conversation – Les stories sont généralement vagues au départ, pour mener à un plus grand échange entre les différentes parties impliquées. Ceci permet que des nouveaux besoins puissent être intégrés plus facilement dans la construction du Backlog produit. Les détails seront ajoutés après les différents échanges, étant définis lors du troisième et dernier C. La composante « Conversation » d’une User Story est souvent oubliée, mais pourtant fondamentale pour partager la meilleure compréhension possible du besoin entre les différentes parties prenantes, et générer aussi une co-construction du produit entre ces parties prenantes ;
Une Confirmation – Pour qu’une Story soit prise en compte par l’équipe Scrum, il faut que le Product Owner (représentant ici les différentes parties prenantes) définisse un critère d’acceptation. Ce critère représente la compréhension du Product Owner de quand pouvons-nous dire que l’objectif de la Story a été atteint. Une bonne règle pour le critère d’acceptation c’est qu’il faut qu’il tienne derrière la carte utilisée pour exprimer la Story. Si le critère ne tient pas derrière la carte, ça peut être un indicateur qu’il faudrait diviser cette Story en plusieurs.
INVEST
Bill Wake nous a donné un critère très répandu pour les bonnes User Stories : l’acronyme INVEST. Par ce critère, les User Stories doivent être :
Si une User Story respecte les 3C et l’INVEST, nous avons sa Definition of Ready – son critère d’acceptance.
Voici ci-dessous un exemple des composantes et du formalisme d’une bonne User Story (extrait de la formation « Devenir Product Owner » d’Invivoo)
Titre :
Pouvoir ajouter un produit dans mon panier
Description :
En tant que client,
Je souhaite pouvoir ajouter un produit dans mon panier
Afin de pouvoir l’acheter
Règles métiers :
Le bouton ajouter au panier sur la fiche produit apparait si il reste un produit en stock public. (stock marchand – stocke réservé)
Quand j’ajoute un produit au panier, le client arrive sur la page panier
Si j’ajoute un produit au panier, ça le réserve pendant 1h
Quand j’ajoute le produit au panier et que j’ai déjà ce produit au panier, on rajoute +1 à la quantité.
Exemple de critère d’acceptance :
Etant donné que je suis sur mon panier
Et que j'ai un produit d'id "1234" en quantité "1"
Et que le stock public restant sur ce produit est de "0"
Et que j'ai ce produit en quantité "0' dans mon panier
Quand je veux cliquer sur le bouton ajouter au panier
Alors rien ne se passe
Conclusion
Cet article clôture une série d’introduction au rôle de Product Owner qui, on l’espère, vous aura éclairer sur les différentes facettes de ce rôle introduit par Scrum. Nous sommes tout à fait conscients que ces articles sont loin d’être exhaustifs, mais ce n’était pas le but. Notre objectif était plutôt d’insister sur les points qui nous semble importants pour assurer et comprendre ce rôle très riche qu’est le Product Owner. Si vous souhaitez en apprendre beaucoup plus ce rôle et être armé pour en devenir un, n’hésitez pas à consulter et vous inscrire à notre formation « Devenir Product Owner ».
