WeFiiT votre partenaire Product Management 360°
Découvrir notre offre

Comment rédiger une Epic ?

Jéromine

Product Owner

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.
 

Qu'est-ce qu'une Epic (épopée) ?

Définition de l'Epic

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.  

Où retrouve-t-on l’Epic?

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.

Les avantages d’une Epic bien structuré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 :  

  • Plus une Epic est structurée, plus il sera simple de la diviser et de limiter les conflits et/ou incompréhension des équipes. Elle est le pilier de référence si des doutes subsistent durant la phase de développement. Elle permet d’optimiser la collaboration au sein de l’équipe et le temps de développement en limitant les corrections, les va-et-vient et les oublis de développement.  
Do the right product and do it right!
  • De plus, elle permet aussi une bonne estimation de la complexité afin de prioriser la roadmap et d’organiser le travail.  
  • Lors du développement, une Epic explicite, dès le titre, permet de suivre cette dernière de manière macroscopique. Cet aspect est important lorsque les user stories qui en découlent sont divisées sur plusieurs briques fonctionnelles et/ou équipes.  
  • Lors de la découpe de l’Epic, les user stories et tâches qui en découlent permettent d’apporter rapidement de la valeur aux utilisateurs au fur et à mesure des sprints.  
  • Les Epics permettent de diviser le travail à réaliser tout en ayant un objectif plus large et commun à différentes équipes.

Les 5 étapes pour construire une Epic

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 !  

Étape 1 : nommer son Epic

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.

Étape 2 : la description / l'introduction

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.

Étape 3 : établir le périmètre de l'Epic

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 :    

  • Uniquement pour les utilisateurs particuliers ;    
  • L'ordonnance ne devra pas être conservée ;    
  • On ne prendra uniquement une photo et un document (JPG- PNG- PDF) ;  
  • L'auto-complétion  ne sera pas implémentée.  

Étape 4 : Quand estimer qu'une Epic est terminée ?

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 :    

  • L'utilisateur peut demander une demande de soin via le formulaire présent sur le site depuis son mobile ou son ordinateur.
  • L'utilisateur peut sélectionner une photo ou un document depuis son appareil.    
  • L'utilisateur peut visualiser le document ou la photo avant de l'inclure à sa demande.
  • L'utilisateur peut visualiser le document en cliquant dessus et revenir sur la demande en fermant la prévisualisation ;  
  • L'utilisateur peut supprimer le document ou la photo sélectionné avant de valider la demande.

Requis Design :  

  • La taille maximum du document ou de la photo ne doit pas dépasser 5mo.  
  • La prévisualisation du document ou de la photo doit être au moins de 600X600 dans le respect des ratios du document.
  • Un indicateur de succès doit être affiché afin de prévenir l'utilisateur que son document /photo est bien attaché à la demande.

Requis technique :

  • Une nouvelle base de données doit enregistrer X ordonnances avec un maximum de 5mo par ordonnance.  
  • L’ID utilisateur de la base de données des demandes utilisateurs en cours, doit être lié à la base de données ordonnance.  
  • Un système de suppression automatique doit supprimer l'ordonnance après la réalisation du soin par le professionnel.

Étape 5 : découper en User Story

À 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 :    

  • Une Epic est un travail, un composant, une fonctionnalité qui peut être découpé en User Stories afin de répondre à un besoin utilisateur précis.      
  • Diviser une Epic en User Stories permet de délivrer de la valeur utilisateur / business en continu.
  • Les Epics permettent de diviser le travail des équipes en ayant un objectif commun.  
  • Une Epic est composée d’un titre explicite, une courte description, d’un périmètre, de critères d’acceptance ainsi que toute information utile à sa compréhension et à son estimation.
Dans la même catégorie
Le no code : un avantage pour les Product Managers
Le no code : un avantage pour les Product Managers
Comment réussir sa sprint review ?
Comment réussir sa sprint review ?
Comment concevoir un produit accessible et inclusif ?
Comment concevoir un produit accessible et inclusif ?
Feature #1 : Product Manager vs Quality Analyst, comment travailler ensemble ?
Feature #1 : Product Manager vs Quality Analyst, comment travailler ensemble ?
Comment améliorer la vélocité de son équipe produit ?
Comment améliorer la vélocité de son équipe produit ?
Comment construire une bonne relation entre QA et DEV ?
Comment construire une bonne relation entre QA et DEV ?