Qu’est-ce vraiment un Epic en Agile ?

Ecrit par << Paquet Judicaël >>

Une question qui pose débat dans l’univers de l’agilité et à laquelle je vais tenter de répondre : qu’est-ce vraiment un Epic en Agile ? Ce débat a été lancé sur des commentaires d’où mon envie de traiter ce point ce soir.

English version : What’s really an Epic in Agile?

Les user-stories viennent de l’Extreme Programming

Ce concept de user-stories n’est pas né avec le Scrum mais avec une autre méthode agile moins connue aujourd’hui appelée Extreme Programming (XP). Le Scrum a en effet emprunté cette façon d’écrire les « items » à l’XP car elles sont vraiment d’une efficacité redoutable.

Qu’est-ce qu’un Epic en Agile

Selon Mike Cohn

Dans l’XP, les Epics (Epopées) sont vulgairement des « Big user-stories » et rien de plus. Parce que cela serait trop simple, Mike Cohn parle même d’Epic pour parler d’une longue histoire qui sera peut-être découpée en user-stories (on en a même pas la certitude) pour être développée. Il est définit par un simple label.

Et pour Mike Cohn, les thèmes sont des ensembles de user-stories regroupées. En effet le regroupement successif « Thème » > « Epic » > « user-stories » qu’on a l’habitude de voir ne correspond pas à 100% à la définition de Mike Cohn.

Si la user-story vient des travaux de Kent Beck lors du projet Chrysler C3, il était intéressant de voir l’avis de Mike Cohn qui a beaucoup partagé sur le sujet (contributeur du Scrum, fondateur de la Scrum Alliance). Cependant, ils sont tous d’accord avec cette définition pas totalement alignée avec celle qu’on au sein des entreprises.

Selon Wikipedia

La définition de Wikipedia va dans le même sens mais simplifie le concept d’Epics : « Une épopée (epic en anglais) décrit des fonctionnalités entières qui englobent de nombreux récits utilisateurs.« .

Ici c’est assez simple, on considère l’Epic comme une fonctionnalité alors que certains framework font une véritable différence entre les deux.

Selon Jira

Incontestablement Jira est devenu un acteur important dans le monde de l’agilité car il fait parti des outils les plus utilisés à ce jour au sein des entreprises. A première vue, on pourrait imaginer que la définition est la même que celle de Wikipedia vu l’utilisation qu’on en fait dans le logiciel ; cependant, on se trompe sévèrement.

Voici l’explication de l’Epic sur le site d’Atlassian (éditeur de Jira) :

« An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.  »

En effet la définition est identique à celle de Mike Cohn. En regardant même de plus prêt, les équipes s’obligent souvent de découper un Epic en plusieurs user-story mais rien ne l’impose ; nous pouvons sans soucis passer un Epic en Done.

Selon SAFe

Je vois déjà certaines voix hurler en lisant l’article mais la vision de l’Epic de SAFe n’en ai pas moins intéressante ; d’ailleurs, le framework utilise le même terme pour définir quelque chose d’assez différent.

Un Epic dans SAFe est un conteneur pour créer une initiative de développement de solutions suffisamment importante qui nécessite une analyse, la définition d’un produit minimum viable (MVP) et une approbation financière avant la mise en œuvre.

Je ne vais pas trop entrer dans le détail mais on est sur quelque chose de beaucoup plus large que dans la définition de Mike Cohn. De plus, le SAFe définit deux types d’Epics : les Business Epics et les Enabler Epics.

Voici un exemple de format proposé directement sur le site de SAFe :

Epic format dans SAFe
Epic format dans SAFe

Mais qu’elle est la bonne définition alors ?

Si on met de côté SAFe qui est selon moi un cas particulier mais intéressant, voici la définition exacte de l’Epic.

A priori, le backlog se décompose de cette façon :

  • Themes
  • Epic
  • User-story (optionnelle)

L’Epic est la forme initiale de la user-story mais n’est pas considéré comme un lot de user-stories à la base. On pourrait parler d’Epic pour parler d’un démarrage de travail d’un backlog.

Cependant si l’Epic est trop gros (par exemple pas développable en 1 seul sprint), on le découpera en plusieurs user-stories.

Du coup nos développeurs pourraient développer des Epics et des users-stories en Scrum (voire XP). Et c’est cette notion qui n’est pas comprise dans les entreprises.

Il n’est même pas rare parfois de voir des équipes faire des regroupements de user-stories sous un label qu’elles appellent des Epics ; mais c’est en fait une mauvaise façon de faire qui contourne la définition initiale de l’Epic.

Personne n’utilise cette version de l’Epic !

C’est malheureusement la complexité que rencontre des formateurs que je connais ; comment expliquer ce qu’est un Epic si personne ne respecte cette définition ? Pourquoi ne pas dire vulgairement qu’un backlog se décompose simplement par thèmes découpés par Epics eux mêmes découpés par user-stories ?

Pour ma part, j’essaye d’expliquer aux équipes mais selon la maturité de celles-ci, on arrive vite au classique : Theme -> Epic -> user-story. Ce découpage simplifié semble bien plus simple à comprendre pour des équipes parfois totalement perdues lors de leur entrée dans le monde des méthodes agiles.

Je comprends ceux qui veulent prêcher la bonne définition bien qu’ils se font rares à réellement la connaitre, pour ma part, je laisse les équipes mettre les mots avec lesquels elles se sentent le plus à l’aise possible.

Si elles veulent appeler ça une « functionality », je leur laisse le faire ; ce qui compte, c’est qu’une légende est affichée sur le mur pour expliquer chaque élément qu’on utilise afin que tout visiteur comprenne le référentiel utilisé.

Et vous votre avis sur le sujet ? Et chez vous, qu’est-ce qu’un Epic ?

[ Article lu 87 fois aujourd'hui ]

7 réponses sur “Qu’est-ce vraiment un Epic en Agile ?”

  1. Article intéressant. Je peux comprendre votre point de vue et la nécessitée d’avoir de la précision dans l’application des définitions. Cependant je ne vois pas l’utilité de définition de l’Epic qe vous retenez. Elle ajoute de la confusion. Si par exemple les developpeurs doivent tantôt developper des épics, tantôt des users stories ou encore dans un outil de gestion on a dans une liste de US et Epics d’une part, et une liste d’Epics qui font références à des US d’autre part… Ben on est bien vite embrouillé. Je pense qu’il faut rester pragmatique. Les auteurs avaient donné une définition qui correspondait à un contexte peut être légèrement différent. du context actuel.

    1. Les développeurs ne développent que des user-stories. Les Epics sont un premier découpage gros maille de la partie fonctionnelle. Les Product Owner doivent travailler de façon itérative et incrémental donc ils ne transformeront ces Epics qu’au moment où cette partie fonctionnelle partira en développement. Un Epic peut devenir 1 user-story ou plusieurs user-stories. Considère l’Epic comme un brouillon sur lequel le travail n’est pas assez avancé pour lancer les développements.
      C’est d’autant plus utile aujourd’hui qu’avant 🙂 Ce travail incrémental et itératif a tendance à être oublié d’où l’intéret majeur de rappeler ce qu’est un Epic.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.