Aller au contenu

Comment rédiger un Epic ?

En tant que Product Manager et Product Owner, écrire un Epic est l’un des piliers essentiels à connaître et maîtriser. Si vous arrivez dans le monde du produit ou que vous souhaitez vous améliorer dans la rédaction d’un Epic, ce qui est fait pour vous ! En d’autres termes, ce guide va vous permettre de mieux comprendre l’Epic, où il se situe dans la roadmap et le backlog, les bénéfices pour toute l’organisation et les étapes clés d’un Epic structuré.  

Sommaire

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

Définition de l'Epic

Selon Mike Cohnun 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éeon 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 actionet des tâches claires et concises pour chaque acteur de l’épopée 

Où retrouve-t-on les Epics ?

L’Epic est présent 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).  
Par conséquent, il est important de bien décrire les Epics afin de prioriser de manière cohérente la roadmap.  

Attention, un Epic peut-être découpé en plusieurs User Stories mais, cela n’est pas une règle immuableL’une des méthodes pour estimer si un Epic a besoin d’être divisé, est d’utilisé l’acronyme INVEST (independentnegociablevaluable, estimable, small, testable). Considérons par exemple, que le poids de l’Epic est supérieur à 20, et qu’il faut plus qu’un sprint pour l’implémenter, alors il est important de le découper. Ainsi, les équipes peuvent embarquer une partie de l’Epic lors d’un prochain sprint.  

Les avantages de réaliser de bons Epics

En tant que Product Owner ou Product Manager, il est de votre devoir de bien écrire un Epic et cela pour de nombreuses raisons : 

  • Plus un Epic est bien structuré, plus il sera simple de la diviser et de limiter les conflits et/ou incompréhension des équipes. Il est le pilier de référence lors de doutes durant les phases de développement. Il permet d’optimiser la collaboration 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, il permet aussi une bonne approximation de la complexité afin de prioriser la roadmap et d’organiser le travail.  
  • Lors du développement, un 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.  
Roadmap produit avec Epic

Les 5 étapes pour construire un Epic

Afin de vous aider à rédiger des Epics structurés, compréhensibles et faciliter le travail de chaque membre de l’équipe en commençant par vous, nous détaillons les principales étapes de la rédaction d’un 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 :  
Vous travaillez avec votre équipe sur un service de demande de soin à domicile. Vous souhaitez 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

Étape 2 : la description / l'introduction

Ces premiers éléments permettent d’expliquer à quoi va servir cette fonctionnalité / ce composant et expliquer ce qu’on souhaite atteindre à travers cet 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’information provenant de la phase de Discovery comme les raisons de la création de cette fonctionnalité, les recherches utilisateurs, les métriques qu’on souhaite améliorer.  
À l’ensemble de ces informations, vous pouvez ajouter des documentations, 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 partager 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 d’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, les 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 peut 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 par conséquent 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 : définir quand estimer qu'un Epic est terminé

Afin que les équipes puissent déclarer qu’un Epic est réalisé / validé, il est nécessaire de lister les requis produit, technique et design sous forme de critères d’acceptance.  
Comme la definition of done (DoD), les critères doivent rester assez “génériques”.  

Attention : un Epic ne s’écrit pas seul.e. En tant que Product Owner / Product Manager, il est de votre responsabilité d’écrire l’intro et les requis produit. N’hésitez pas à solliciter les membres de votre équipe tels que le Lead Dev pour compléter les requis technique et le Product Designer ou l’UX Designer / Lead pour la partie requis 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é. Si nécessaire, c’est à ce moment qu’il est judicieux de la diviser en plusieurs user-stories afin que les équipes dev puissent lors du sprint planning les estimer et les “embarquer” dans les prochains sprints.  

Pour conclure, un 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’un Epic structuré et complète. En fonction de votre entreprise et des pratiques en place, l’aspect peut être modifié, les termes employés peuvent être différents et d’autres informations peuvent s’ajouter. 

Ce qu’il faut retenir :  

  • Un 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 un 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. 
  • Un Epic est composé d’un titre explicite, une courte description, d’un périmètre, de critères d’acceptance ainsi que toute information utile pour la compréhension et l’estimation d’un Epic.