The hidden power of soft skills for Product Managers
What soft skills should a good Product Manager have? Through their testimonials, Product experts explain to you!
En tant que Product Owner, vous en avez sûrement fait l’un de vos principaux outils de travail au quotidien. Censées guider le développement en décrivant le besoin fonctionnel pour répondre à un problème utilisateur, les User Stories viennent garnir le backlog de tout bon produit.
Dans les méthodes agiles, une User Story (de son petit nom US) est une phrase simple, rédigée dans un langage courant, qui permet de décrire avec suffisamment de précision le contenu d'une fonctionnalité à développer.
Dans la méthode agile Scrum dont elle est issue, la User Story est censée illustrer un besoin fonctionnel exprimé par les types d’utilisateurs. Elle vise ainsi à assurer que l’on délivre bien de la valeur pour nos usagers.
Pour le Product Owner, l’intérêt de rédiger des User Stories est triple :
La création d’une User Story est donc a priori très simple : en fonction des besoins des utilisateurs ou de la technique, le Product Owner rédige la tâche à accomplir et l’ajoute à son backlog. Quelques minutes de travail et le tour est joué ?
Si seulement…
En réalité, rédiger une belle User Story nécessite :
Avant d’être retranscrite et proposée au développeur, la problématique fonctionnelle que l’on souhaite aborder nécessite d’être défrichée.
C’est au sein du cycle itératif qui précède le développement et qui a pour objectif d’accoucher du backlog produit, que naît la User Story. Si les User Stories sont le carburant du développement, celui-ci ne représente qu’une petite partie de leur vie. La conception qui le précède peut démarrer des semaines, voire des mois avant le sprint et se déroule également selon des itérations.
Loin d’être une réflexion initiale rédigée à la va-vite sur un bête post-it, la rédaction d’une User Story est plutôt le point final d’un long cycle de recherches, de réflexions, d’échanges et d’ateliers en équipes.
Au commencement d’une Story fonctionnelle se trouve un besoin. Qu’il soit exprimé directement par l’utilisateur du produit ou remonté par les parties prenantes, et formulé de manière plus ou moins précise, il convient de l’explorer davantage pour être en capacité de le traduire par la suite en fonctionnalité.
Pour cela, le Product Owner dispose de nombreux outils de recherche utilisateur, comme par exemple les interviews, et peut également réaliser des ateliers avec les interlocuteurs métiers dans le but de monter en compétences sur le sujet fonctionnel et de creuser le besoin.
Une fois le besoin recueilli et précisé, le Product Owner va se réunir avec son équipe produit (ex : UX designer, architecte, lead développeur…) pour réfléchir à des pistes de résolutions de ce besoin en fonction des possibilités techniques.
Une fois défrichés, les sujets passent sous la baguette magique du Product Designer (qui est responsable de l’expérience utilisateur) qui exprime les solutions possibles sous la forme de maquettes fonctionnelles. Dans l’idéal, ces dernières sont testées auprès d’un panel représentatif des types d’utilisateurs, afin d’améliorer les fonctionnalités désignées et d’identifier la solution répondant le mieux au besoin exprimé.
Une fois qu’il dispose de représentations visuelles du sujet fonctionnel et d’une bonne vision sur les problématiques techniques, le Product Owner et son équipe vont pouvoir découper le besoin en fonctionnalités facilement développables par l’équipe.
Pour cela, l’équipe peut réaliser un
. Cet atelier consiste en la définition des grandes étapes fonctionnelles du parcours utilisateur, les Epics, qui sont ensuite découpées en Stories exhaustives. Ainsi représentées, les Stories sont plus faciles à ordonner et à prioriser, et permettent de créer un parcours logique et débarrassé de son superflu.
En fonction des délais, du budget ou du périmètre à couvrir, nombre d’idées prédestinées à devenir des User Stories vont être dépriorisées voire abandonnées.
Concevoir des User Stories, c’est aussi faire des choix pour le bien du produit.
Afin d’avoir une vision sur le cycle de conception des User Stories et d’être plus efficace, le Product Owner peut représenter le processus sous la forme d’un Kanban, disposant par exemple des étapes À FAIRE > RECHERCHE UTILISATEUR > ATELIERS INTERNES > WIREFRAMES > DÉCOUPAGE > PRÊT À RÉDIGER.
Illustré grâce à du management visuel, ce Kanban peut également faire l’objet de stand-up meetings de conception. Cette méthode permet de suivre au mieux l’avancée des différents sujets fonctionnels, d’avoir une meilleure visibilité sur les travaux de défrichage en cours, d’identifier les blocages et d’être plus efficace lors de cette étape.
Si différents modèles de formulation des User Stories existent, il est fondamental que le Product Owner en adopte un qui inclut les dimensions “qui”, “quoi” et “pourquoi”.
Indispensables, ces trois éléments permettent de structurer le contenu de telle sorte qu’il exprime clairement la valeur ajoutée de la fonctionnalité, mais aussi le bénéficiaire.
La formulation la plus simple et connue d’une User Story est donc :
Sous leur format anglo-saxon, les User Stories se présentent sous la même forme :
À savoir que le “en tant que” ne désigne pas forcément un type d’utilisateur final du système, mais tout rôle concerné par le produit : utilisateur final d’un certain segment, testeur, développeur, administrateur, etc.
La User Story dépasse souvent le cadre de la simple phrase. Le Product Owner peut y ajouter tous les éléments qui vont permettre à l’équipe de développement de prendre en charge l’implémentation complète de la fonctionnalité, comme par exemple :
Chez Hubvisory, nous mixons BDD et Gherkin afin d’aboutir au format suivant pour nos User Stories :
Le framework de User Story que nous utilisons chez Hubvisory
Par ailleurs, chaque User Story s’inscrivant dans un groupe plus large - une Epic - constituant une fonctionnalité, il peut être nécessaire de référencer l’Epic à laquelle la User Story est liée.
Enfin, si l’équipe emploie un management visuel pour gérer ses tickets de développement, il est assez coutumier que seules des abréviations des User Stories soient notées sur les post-it, afin de pouvoir conserver une vue d’ensemble sur les Stories en développement.
Par exemple, pour une User Story “En tant qu’assuré, je veux pouvoir prendre un rendez-vous avec un expert afin de constater mon dommage de dégât des eaux”, on pourrait écrire sur le post-it quelque chose comme “Prise RDV expert”.
Il convient cependant de noter qu’une User Story ne se suffit pas à elle même et ne remplace en rien la rédaction de spécifications associées. Dans les pratiques agiles, la User Story reste un outil de communication tandis que les spécifications (techniques et fonctionnelles) viennent très largement la compléter et lui donner du corps.
Afin de vérifier que la User Story que l’on a rédigée est de qualité (et permettra donc de construire un produit tout aussi qualitatif), on peut chercher à respecter les 6 adjectifs qui composent l’acronyme INVEST :
Facile à retenir, INVEST permet de garder en tête les principales caractéristiques d’une User Story de qualité.
Acronymes un peu barbares, la DoR (Definition Of Ready) et la DOD (Definition of Done) permettent d’englober l’ensemble des critères que l’équipe définie pour qualifier l’état “Prête à développer” et l’état “Terminée” de la User Story.
Tirés du cadre méthodologique Scrum, ses artefacts permettent de valider collectivement le passage de la User Story d’un état à un autre.
En français “Définition de prêt”, la DoR est un ensemble de critères qui déterminent si une User Story est prête à être traitée par l’équipe de développement.
Traditionnellement, on utilise les “6D” pour définir sa DoR. Pour être prête à être développée, la User Story doit ainsi être :
Si la User Story remplit l’ensemble de ses critères, elle sera alors “Ready to dev”, c’est à dire qu’elle pourra faire l’objet d’un travail dès l’itération à venir.
D’autres critères, plus en lien avec la rédaction de la Story peuvent également être inclus dans la DoR. On peut par exemple demander à ce que la Story contienne les éléments suivants :
On peut également valider que les processus définis par l’équipe pour construire ses User Stories de qualité ont bien été suivis en demandant :
En français “Définition de fini”, la DoD permet de définir si une User Story peut-être considérée comme terminée, car plus aucun travail en lien avec elle ne sera nécessaire.
Les critères mis en place dans la Definition of Done doivent permettre deux choses :
Les éléments qui peuvent définir la Definition of Done sont par exemple :
La place de la DOR et de la DOD dans le cycle de vie de la User Story
Établir une DoR et une DoD aide l’équipe à s’engager sur le sprint à venir et à se cadrer.
La Definition of Ready doit permettre d’éviter à l’équipe de développement de commencer à travailler sur une User Story qui ne serait pas assez claire ou précise, ce qui engendrerait des allers-retours coûteux et chronophages.
Par ailleurs, instaurer une DoR oblige l’équipe à l’anticipation : pour pouvoir embarquer des Stories, elle doit préparer et affiner son backlog en amont de chaque Sprint, ce qui lui permet de mieux connaître ses User Stories, de les estimer avec davantage de certitude, et donc de plus facilement atteindre son engagement.
Quant à la Definition of Done, sa définition par l’équipe permet d’éviter de commencer trop de choses sans réellement les finir, ce qui pourrait nuire à la qualité du produit. En Scrum, il est également nécessaire qu’une User Story soit “done” pour qu’on puisse compter les points de vélocité de l’équipe, et donc de calculer sa productivité d’un sprint à l’autre.
De l’idée initiale à sa mise en production, nous avons vu qu’une User Story parcourt tout un cycle de vie. Et si sa création est soumise à de nombreuses contraintes, une User Story de qualité n’est pas qu’une User Story rédigée selon toutes les bonnes pratiques. C’est avant tout un outil de communication que l’équipe à su s’approprier, notamment en personnalisant sa structure à ses besoins.
Quelle que soit la forme de User Story choisie, celle-ci doit être connue et partagée de tous, afin que l’équipe soit alignée et que les User Stories deviennent un outil efficace et pérenne pour la création du produit.
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision