Définition

En agile, une epic est un besoin de grande taille, formulé de manière volontairement large, qui ne peut pas être livré à l'intérieur d'un seul sprint et que l'on découpe plus tard en plusieurs user stories. Elle sert à garder une vue d'ensemble du produit sans écrire le détail trop tôt. Le mot vient de l'anglais et se traduit par épopée : une histoire trop longue pour être racontée d'une traite.

« Permettre au client de gérer son compte » ou « refondre le parcours de paiement » sont des epics typiques. Chacune se décomposera en une série de user stories livrables une par une.

La place de l'epic dans le backlog

Un backlog produit sain mélange les granularités : ce qui sera traité bientôt est détaillé, ce qui est lointain reste gros. L'epic occupe le bas de cette liste.

NiveauCe que c'estTaille indicativeQui l'écrit
EpicUn besoin large, non livrable tel quelPlusieurs sprintsLe product owner
User storyUn besoin vu par l'utilisateur, livrable et testable seulUne fraction de sprintLe product owner, affinée avec l'équipe
TâcheLe travail technique nécessaire à une storyQuelques heures à quelques joursLes développeurs

Le passage de l'epic à la story se fait pendant le raffinement du backlog, avant de pouvoir prendre l'élément en sprint. Le product owner en est responsable, sans le faire seul : le découpage réclame l'avis de ceux qui vont construire.

Découper une epic

Découper une epic consiste à en tirer des tranches qui apportent chacune une valeur observable et tiennent dans un sprint. Les axes les plus utiles sont le parcours utilisateur étape par étape, les variantes de règles métier, les types d'utilisateurs concernés, et la séparation entre le cas nominal et les cas particuliers. Une tranche qui ne se démontre pas en fin de sprint est mal découpée.

Le réflexe à éviter est la découpe par couche technique : une story pour la base, une pour l'interface, une pour l'API. Chacune est estimable, aucune n'est démontrable.

Ce que dit le Scrum Guide 2020

Le Scrum Guide 2020 (Schwaber et Sutherland) ne définit ni l'epic ni la user story. Il ne connaît que le Product Backlog et ses éléments, sans imposer de format ni de niveaux de granularité. Epic et user story sont des pratiques d'usage, répandues et utiles, mais extérieures au cadre Scrum lui-même.

Le guide décrit en revanche le raffinement du Product Backlog comme la décomposition des éléments en éléments plus petits et plus précis, et pose qu'un élément doit pouvoir être terminé dans un sprint pour être retenu en planification. C'est le besoin auquel répond le découpage d'une epic. Aucune définition officielle n'en tranche donc la taille : mieux vaut s'accorder en équipe, et replacer ces notions dans leur cadre d'origine sur ma page consacrée à Scrum.

Les erreurs fréquentes

  • Détailler trop tôt. Vingt stories écrites pour un besoin traité dans six mois seront caduques avant d'être prises.
  • Prendre une epic en sprint. Un élément trop gros finit à moitié fait et se reporte, faussant la vélocité.
  • Découper par couche technique. Le résultat est estimable mais indémontrable, et le retour utilisateur arrive trop tard.
  • Empiler les niveaux. Initiative, thème, epic, feature, story, sous-tâche : chaque étage coûte de la maintenance pour un gain qui s'épuise vite.

Les termes voisins à ne pas confondre

  • User story. Elle exprime un besoin du point de vue de l'utilisateur, avec des critères d'acceptation, et se livre dans un sprint.
  • Feature. Une fonctionnalité telle qu'on la nomme dans une plaquette ; selon les outils, au même niveau que l'epic ou juste en dessous.
  • Thème. Un regroupement d'éléments qui partagent un même domaine, utile au classement du backlog, pas à la planification.
  • Tâche. Le travail technique par lequel les développeurs réalisent une story. Elle ne se présente pas à un utilisateur.

Le test que j'applique à toutes les epics d'un backlog.

Je demande au product owner de me raconter, pour chaque epic, la première tranche qu'il livrerait s'il ne devait en livrer qu'une. Quand il répond en trente secondes, l'epic est mûre. Quand il ne sait pas par où commencer, le besoin n'est pas encore compris, et écrire des stories revient à mettre de l'ordre dans un brouillard.

Discuter du pilotage de votre projet

Questions fréquentes

Non. Le Scrum Guide 2020 de Ken Schwaber et Jeff Sutherland ne mentionne ni l'epic ni la user story. Il décrit le Product Backlog et ses éléments, sans imposer de format d'écriture ni de niveaux de granularité. Il définit en revanche le raffinement du Product Backlog comme la décomposition des éléments en éléments plus petits et plus précis, ce qui est précisément l'usage du découpage d'une epic.
Aucun nombre ne fait règle, et se fixer une cible produit des découpages artificiels. Le seul critère qui compte est que chaque story issue de l'epic apporte une valeur observable et tienne dans un sprint. Certaines epics donnent trois stories, d'autres une vingtaine selon l'ampleur du besoin. Une epic dont on ne sait tirer qu'une seule story n'était probablement pas une epic.
Le product owner en est responsable, comme il l'est de l'ensemble du Product Backlog dans Scrum. Il crée les epics, les ordonne et décide de celles que l'on va instruire ensuite. Le découpage en stories se fait toutefois avec les développeurs, qui apportent la connaissance technique nécessaire pour identifier des tranches réellement livrables.
Laurent Tulpan

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il accompagne des équipes produit dans la tenue et le découpage de leur backlog, sur des projets menés pour des grands comptes et des PME (TF1, SFR, Orange, SNCF). Découvrir son approche.

À lire ensuite