%20(1).jpg)
Camille
·
August 7, 2024
En tant que Product Manager et Product Owner, écrire une Epic est l’un des piliers essentiels à connaître et maîtriser. Si tu débutes dans le monde du produit ou que tu souhaites t’améliorer dans la rédaction d’une Epic, cet article est fait pour toi !
En d’autres termes, ce guide va te permettre de mieux comprendre l’Epic, où elle se situe dans la roadmap et le backlog, ses bénéfices pour l’organisation et les étapes clés pour une Epic structurée.
Selon Mike Cohn, une Epic, ou une épopée en français, représente une large User Story et se situe entre le thème / initiative et les User Stories qui en découlent.
Mike Cohn utilise, dans son livre User Story Applied, l’analogie d’un film d’action pour expliquer comment les différents termes s’articulent.
Par conséquent, on peut imaginer l’épopée comme une grande histoire avec plusieurs acteurs, un peu à la manière de Momento où l’histoire, qui se décompose en scénettes (User Stories), est vue sous le prisme de différents personnages.
Pour réaliser cette épopée, on a donc plusieurs petites histoires avec potentiellement des utilisateurs différents.
De ce fait, il est important pour une épopée d’avoir un cadre avec des actions et des tâches claires et concises pour chaque acteur de l’épopée.
L’Epic est présente dans la Roadmap et le Backlog car elle permet de représenter des briques fonctionnelles (fonctionnalités ou composants) que les équipes de développement peuvent estimer de manière macroscopique (ex : T-shirt sizing).
Il est donc important de bien décrire les Epics afin de prioriser de manière cohérente la roadmap.
Attention, une Epic peut-être découpée en plusieurs User Stories mais cela n’est pas une règle immuable. L’une des méthodes pour estimer si une Epic a besoin d’être divisée est d’utiliser l’acronyme INVEST (Independent, negociable, valuable, estimable, small, testable).
Considérons par exemple, que le poids de l’Epic est supérieur à 20 et qu’il faut plus d’un sprint pour l’implémenter, alors il est important de la découper en plusieurs User stories. Ainsi, les équipes peuvent embarquer une partie de l’Epic lors d’un prochain sprint.
Tips : Même si l'Epic est à un haut niveau de développement, il est important de la détailler afin qu'elle soit compréhensible par l'ensemble des parties prenantes et qu'elle soit correctement estimée.
En tant que Product Owner ou Product Manager, il est de ton devoir de bien écrire une Epic et cela pour de nombreuses raisons :
Do the right product and do it right!
Afin de t’aider à rédiger des Epics structurées, compréhensibles et faciliter le travail de chaque membre de l’équipe, en commençant par toi, nous détaillons les principales étapes de la rédaction d’une Epic. En vue de rendre l’exercice plus concret, les étapes sont illustrées par un exemple sur la création d’une nouvelle fonctionnalité dans le domaine de la Medtech !
En premier lieu, l’intitulé de l’Epic doit être unique, clair, concis et écrit dans un langage compréhensible par toute l’organisation. Débuter par le nom, permet de clarifier les objectifs.
Pour illustrer cette étape prenons un exemple :
Tu travailles avec ton équipe sur un service de demande de soin à domicile. Tu souhaites ajouter une fonctionnalité afin que les demandeurs puissent attacher une ordonnance à leur demande de soin.
Ainsi, le titre serait : Ajout ordonnance sur demande de soin
Tips : Accordes-toi sur une manière standard d'écrire le nom de l'Epic permet de limiter les confusions entre les équipes.
Ces premiers éléments permettent d'expliquer à quoi va servir cette fonctionnalité / ce composant et ce qu'on souhaite atteindre à travers l’Epic.
En fonction des organisations, certaines utilisent une phrase standard pour expliquer Qui (l'utilisateur cible) / Quoi (l'objectif) / Pourquoi (la valeur derrière l'objectif).
En plus de la courte description, il est important d'apporter plus d'informations provenant de la phase de Discovery comme les raisons de la création de cette fonctionnalité, les recherches utilisateurs, les métriques que l’on souhaite améliorer.
À l'ensemble de ces informations, tu peux ajouter de la documentation, le plan marketing, les requis d'autres départements (ex : légal) et les premiers wireframes.
En reprenant l'exemple ci-dessus, l'introduction pourrait-être :
Cette fonctionnalité permettra aux demandeurs de soin d'attacher une ordonnance à leur demande et de la partager avec le professionnel sélectionné.
“En tant que patient réalisant une demande de soin,
Je veux pouvoir attacher une ordonnance
Afin de partager les détails de mon soin avec le professionnel qui viendra le réaliser.”
“En tant que professionnel ayant accepté la demande de soin,
Je veux pouvoir visualiser l'ordonnance du patient
Afin de prévoir les bons équipements et organiser ma journée en fonction de la charge de travail du soin.”
Lors des recherches, on a relevé que 60% des demandeurs de soin ne précisent pas l'ensemble des détails de l'ordonnance, car ils sous-estiment l'importance que cela peut avoir sur le soin.
Le questionnaire envoyé aux patients n’ayant pas finalisés la demande de soin montre que la principale raison d'abandon est l'obligation de détailler la demande. De surcroît, 75% des professionnels estiment que 2/3 des soins sont peu ou pas détaillés et doivent faire des hypothèses sur le réel besoin du patient. Nous avons pour objectif de diminuer le taux d'abandon de demande de 10% et d'augmenter la satisfaction des professionnels de 5%.
Idéalement, nous souhaitons que l'ordonnance puisse remplir automatiquement les champs du formulaire, mais pour le MVP nous avons décidé que le patient pourra uniquement télécharger un document ou prendre une photo de son ordonnance depuis son portable et ordinateur.
Il est important de préciser l'étendue du travail et ses limites d'application. Délimiter une épopée permet de cadrer l'équipe et de pouvoir plus facilement estimer la charge de travail.
En reprenant notre exemple d'ajout d'une ordonnance, le périmètre serait :
Afin que les équipes puissent déclarer qu'une Epic est réalisée / validée, il est nécessaire de lister les requis produit, technique et design sous forme de critères d'acceptance.
Comme dans le cadre de la definition of done (DoD), les critères doivent rester assez "génériques".
Attention : une Epic ne s'écrit pas seul. En tant que Product Owner / Product Manager, il est de ta responsabilité d'écrire l'intro et les requis produit. N'hésite pas à solliciter les membres de ton équipe tels que le Lead Dev pour compléter les requis technique et le Product Designer ou l'UX Designer / Lead pour la partie design.
En reprenant l'exemple ci-dessus, les exigences produit, design et technique seraient :
Requis produit :
Requis Design :
Requis technique :
À cette étape, l'Epic est techniquement terminée. Si nécessaire, c'est à ce moment qu'il est judicieux de la diviser en plusieurs user stories afin que les équipes techniques puissent, lors du sprint planning, les estimer et les "embarquer" dans les prochains sprints.
Pour conclure, une Epic est un moyen d'aligner toutes les parties prenantes de l'organisation et de donner une idée macro de ce qu'on souhaite réaliser à plus ou moins long terme. Les étapes listées ci-dessus sont la base d'une Epic structurée et complète. En fonction de ton entreprise et des pratiques en place, l'aspect peut en être modifié, les termes employés peuvent être différents et d'autres informations peuvent s'ajouter.
Ce qu’il faut retenir :
WeFiiT vous accompagne pour construire ensemble des produits à impact, au cœur d’une équipe engagée et passionnée.
Prendre RDV maintenant
.jpg)
.jpg)
.jpg)
