L'epic en agile : définition et découpage

Une epic est un besoin trop gros pour tenir dans un sprint, que l'on garde volontairement large tant qu'on ne sait pas encore comment le traiter. C'est un mot d'usage et d'outillage, absent du Scrum Guide 2020, ce qui explique qu'on lui donne des sens très différents d'une équipe à l'autre. Je détaille ici sa place dans le backlog et la manière de la découper.

Le vocabulaire du projet digital, expliqué simplement

Laurent Tulpan, directeur de projet digital
Publié le 28 août 2026, mis à jour le 9 octobre 2026, lecture 4 min

Définition de l'epic

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 avec les epics

  • 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 de l'epic

  • 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

Comment suivre l'avancement d'une epic ?
En suivant deux nombres : les stories terminées et le total des stories de l'epic. Le total bouge, car le découpage continue pendant que l'équipe avance, et c'est lui qu'il faut surveiller. Si le reste à faire grossit plus vite que ce qui est fait, l'epic n'a pas de fin en vue. Le product owner doit alors couper, livrer la partie qui apporte déjà de la valeur et renvoyer le reste au bas du backlog. Un pourcentage d'avancement qui stagne des semaines durant signale le même problème.
Combien de user stories sort-on 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.
Qui est responsable des epics du backlog ?
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.

À lire ensuite

Parlons de votre projet

Un premier échange de vingt minutes suffit en général pour comprendre votre situation et vous donner des pistes concrètes. Réponse sous 24 h ouvrées, par la personne qui pilotera votre projet.

Laurent TulpanLaurent Tulpanvous répond sous 24 h