Une question qui pose débat dans l’univers de l’agilité et à laquelle je vais tenter de répondre : qu’est-ce vraiment des Epics Agile ? Ce débat a été lancé sur des commentaires d’où mon envie de traiter ce point ce soir.
Vous pouvez regarder la vidéo de la minute agile sur le sujet :
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 que les Epics en Agile
Les Epics 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’Epics 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èmes » > « Epics » > « 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 ; il est l’un des contributeurs du Scrum et 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 ce concept : « 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 celles-ci comme des fonctionnalités 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é ; en effet, 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 des Epics 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 les Epics en plusieurs user-stories mais rien ne l’impose ; nous pouvons sans soucis passer des Epics directement en Done.
Selon SAFe
Je vois déjà certaines voix hurler en lisant cette partie de l’article ; cependant la vision des Epics 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.
Des Epics dans SAFe sont des conteneurs 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 en définit deux types : les Business Epics et les Enabler Epics.
Voici un exemple de format proposé directement sur le site de 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 des Epics.
A priori, le backlog se décompose de cette façon :
- Themes
- Epics
- User-stories (optionnelle)
Les Epics sont 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’Epics pour parler d’un démarrage de travail d’un backlog.
Cependant si elles sont trop grosses (par exemple pas développable en 1 seul sprint), on les 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 des Epics.
Personne n’utilise cette version des Epics !
C’est malheureusement la complexité que rencontre des formateurs que je connais ; comment expliquer ce que sont des Epics si personne ne respecte cette définition ? Pourquoi ne pas dire vulgairement qu’un backlog se décompose simplement par thèmes / Epics / user-stories ?
Pour ma part, j’essaye d’expliquer aux équipes mais selon la maturité de celles-ci, on arrive vite au classique :
Themes -> Epics -> user-stories.
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 des Epics ?
Lien utile : lancer des projets 100% en agile avec le framing agile
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.
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.
Bonjour,
voir le lien:
https://www.linkedin.com/pulse/writing-good-epics-manoel-pimentel-medeiros
Ça date un peu mais je trouve cela intéressant.
Bonne lecture
Bonjour Judicaël Paquet,
Si je comprends bien PO travail sur les thèmes et les EPIC, éventuellement, l’équipe de développement affine ces EPIC en user-story plus précise, soit lors sprint planning pour permettre la négociation avec PO de ce que peut embarquer l’équipe de développement, ou soit lors lors du sprint pour diviser le travail par exemple entre plusieurs membres de l’équipe.
SCRUM ne définis pas cet artefact mais est-ce une bonne pratique de l’utiliser ?
Je vois également certaine ressource qui user-story utilisé comme des thèmes composés de task. Y-a t-il d’autres éléments ?
Bonne journée,
Hello Anthony,
Non, le PO travaille sur les user stories également. Du moins il en a la responsabilité mais il peut déléguer à un PPO/BA.
L’équipe de développement et le PO vont créer le sprint backlog ensemble lors de la sprint planning.
« Je vois également certaine ressource qui user-story utilisé comme des thèmes composés de task. » => je n’ai pas compris ta question.
Bonjour,
Personnellement je vois l’épopée comme une grande histoire avec plusieurs acteurs, un peu à la manière de Pulp Fiction où l’histoire, qui se décompose en scénettes, est vue sous le prisme de différents personnages.
Pour « raconter » une épopée, on a donc plusieurs histoires utilisateurs avec potentiellement des utilisateurs différents.
Aussi, j’essaie de faire en sorte qu’une épopée soit bornée dans le temps : elle a un début et une fin. Exit donc les épopées « fourre-tout » alimentées au fil de l’eau et qui ne se terminent jamais.
Merci, c’est intéressant 🙂