Epic? vous avez dit Epic ? Définition et explications

Si vous recherchez une définition claire de ce concept d’EPIC dont on vient tout juste de vous parler dans votre organisation, vous êtes au bon endroit! Cet article vous donnera les clés pour comprendre ce qu’est précisément une EPIC et comment l’utiliser.

Mais tout d’abord identifions le contexte dans lequel vous allez être amené(e) à utiliser ces fameuses EPIC car de ce contexte dépendra la définition précise de l’EPIC et de ses caractéristiques principales… Il existe trois contextes d’usage de l’EPIC dans les entreprises; il vous suffit de repérer votre contexte et d’aller directement chercher au coeur de cet article, la définition et les explications qui s’y rattachent :

• Contexte #1 : Agile au sens large (Scrum, Kanban…) et Product Management. Le contexte qui couvre la plupart des situations (donc le plus répandu) avec la définition de l’Epic la plus classique et la plus partagée.

• Contexte #2 : Là où SAFe (Scaled Agile Framework) est mis en place et Gestion de Portefeuille Agile & Lean. Un contexte et un usage encore minoritaire (mais qui tend à se développer) avec une définition spécifique de l’EPIC valable uniquement dans le cadre de ce framework d’agilité à l’échelle et utilisable en gestion de portefeuille (l’Epic est alors considèrée comme une large initiative)

• Contexte #3: Dans le cadre de Business Agility ou de Programmes de Change c’est à dire avec une utilisation de l’agilité Hors IT / TECH (un contexte emergent qui reprend les éléments de base du contexte #1)

Contexte 1 : Agile (générique, Scrum, Kanban) & Product Management.

Il s’agit du cas général qui recouvre la plupart de nos situations de travail; vraisemblablement le contexte dans lequel vous interviendrez. Ce contexte porte la définition de l’Epic la plus classique et la plus partagée; c’est donc ce format d’EPIC et cette définition auxquels vous allez potentiellement vous référer.

Une Epic est une User Story de grande taille, estimée trop grosse pour entrer et être terminée dans un sprint. Une epic est ainsi décomposée en des stories plus petites.

Mike Cohn fut le premier à utiliser le terme d’Epic dans son livre « User Sories applied » (2004) : « When a story is too large it is sometimes referred to an epic. Epics can be split into two or more stories of smaller size« . Il ajoute en 2010 dans troisième livre « Succeeding with agile » : « Generally an epic is a user story that will take more than one or two sprints to develop and test« .

Depuis, l’idée qu’une EPIC est une User Story de grande taille (une grande brique fonctionnelle) qui doit être décomposée en des user Stories plus petites pouvant quant à elles être embarquées dans un sprint, est largement partagée dans la communauté agile & produit, francophone et internationale.

Quelques exemples d’EPICS

EPIC : Gestion du panier Client
(US : En tant qu’utilisateur, je veux ajouter un produit au panier / En tant qu’utilisateur, je veux connaitre le coût total de mon panier / En tant qu’utilisateur, je veux choisir mon moyen de paiement)

EPIC : Rechercher une offre d’emploi
(US : En tant qu’utilisateur, je veux rechercher une offre selon des critères précis / US : En tant qu’utilisateur, je veux consulter les offres qui correspondent à mes critères » / US : En tant qu’utilisateur, je veux consulter la description de l’entreprise émettrice de l’offre »… etc)

Tout comme pour les user stories (c’est un must), des critères d’acceptation (ou conditions de satisfaction) peuvent être associées aux Epics.

Dans ce contexte, que deviennent les EPICS une fois splittées?

Deux modes de gestion sont envisageables.

Dans une logique d’affinage progressif, les EPICS peuvent être amenées à disparaitre au profit des stories nouvellement créées (c’est l’option 1 et celle notamment défendue par mon camarade Claude Aubry).

Une autre possibilité est de garder l’EPIC de base pour des raisons de suivi et de traçabilité (c’est l’option 2).

Et les thèmes dans tout cela ?

Les thèmes sont davantage créées à des fins de classification ou de regroupement. Un thème regroupant en son sein plusieurs User Stories (ou même EPICS) liées entre elles. On peut voir le thème comme un attribut ou utiliser un système de tag pour visualiser des stories qui vont ensemble.

Combien de Niveaux d’exigences ?

Si on garde les epics une fois qu’elles sont décomposées en user stories (mode de gestion #2), on se retrouve globalement avec deux niveaux de « requirements » (exigences en français):

• Le niveau EPIC (le plus haut niveau d’exigence, la grosse brique fonctionnelle)
• Le niveau User Story (« ce que l’utilisateur veut »), la plus petite unité fonctionnelle qui elle même pourra être ensuite décomposée en des tâches d’analyse, de développement, de test ou de déploiement accomplies par les membres de l’équipe de développement

D’un point de vue outillage, ces deux niveaux sont facilement gérés par la plupart des outils du marché (Trello, Azure DevOps ou encore Jira qui propose ces deux niveaux : Epic / Story par défaut).

Contexte #2 : SAFe (Scaled Agile Framework) basé sur les travaux de Dean Leffingwell (son créateur) & Gestion de Portefeuille Agile & Lean

L’usage est encore minoritaire (mais tend à augmenter, notamment pour la gestion de portefeuille d’initiatives : Epics, Projets…) et la définition de l’EPIC qui suit sera valable uniquement pour ce framework spécifique d’agilité à l’échelle et donc seulement pour les personnes / équipes évoluant dans un contexte où SAFe est mis en place. Vous ne trouverez ainsi aucune mention d’EPIC dans Scrum@Scale de Jeff Sutherland. Du côté de de LESS (Large Scale Scrum), il est arrivé à Craig Larman & Bass Vodde, créateurs de cet autre framework d’agilité à l’échelle assez populaire d’évoquer la notion d’EPIC mais uniquement en lien avec les user sorties (cf. contexte 1) et avec une forte mise en garde sur la complexité de « meta model » d’exigences. Le message est clair: faites simple et ne multipliez pas les niveaux !

Pourtant, si vous intervenez dans un contexte SAFe (dans le cadre de programmes multi équipes de + de 50 personnes), vous serez amené à manipuler des EPICS (au sens SAFe) et à maîtriser les niveaux (trois) de Requirements qui l’accompagnent. Rassurez-vous, une fois le Train SAFe passé (car l’approche est loin d’être adaptée à la plupart des organisations), vous pourrez revenir à une vie normale 🙂

En attendant, SAFe définit l’EPIC de la façon suivante :

« Un Epic est un conteneur pour le développement d’une solution importante capturant les investissements les plus conséquents qui ont lieu dans un portfolio. En raison de leur portée et impact considérable, les epics requièrent qu’un Minimum Viable Product (MVP) soit défini et approuvé par le Lean Portfolio Management (LPM) avant d’être mis en œuvre. »

Glossaire SAFe 5.1

D’ailleurs personnellement je préférais la définition qu’en donnait Dean Leffingwell dans ses premiers ouvrages « Epics are large-scale development initiatives that realise the value of investment themes » ; aussi ai-je tendance à utiliser une variation de cette définition dans les contextes SAFe et / ou Gestion de Portefeuilles d’initiatives :

« Une Epic est un objectif de valeur soutenant un thème se caractérisant par le développement d’une solution importante »

Dans tous les cas, l’EPIC selon SAFe qui peut être de deux types (Business ou Architectural) est un maillon incontournable du framework. Elle se décompose en Features et n’est pas testée ou implémentée directement (seulement à partir de ses Features).

En terme de taille, elle peut couvrir plusieurs flux de valeurs et plusieurs PI (Program Increments) et donc impacter de trés nombreuses équipes. En terme de durée, le travail d’une Epic, en mode SAFe s’opère sur plusieurs mois.

L’EPIC possède un cycle de vie (Funnel > Review > Analyze > Backlog > Implement > Done). Les Epics sont identifiées, priorisées, estimées et maintenues dans un backlog de portefeuille, idéalement priorisé par la valeur. Je dois avouer que je trouve cette partie de SAFe (le niveau Portefeuille) très intéressante; c’est une base solide pour aborder la gestion de portefeuille d’initiatives, puis travailler avec mes clients, une gouvernance légère et adaptée qu’il convient de mettre en place à ce niveau (maille trimestrielle / mensuelle).

L’EPIC s’initie au travers d’un template et sera porté tout le long de son cycle de vie par un EPIC Owner (notamment sur la partie analyse).

Combien de niveaux dans SAFe ?

Le modèle d’exigences de SAFe se joue sur trois niveaux :

Epics > (L’epic est le conteneur pour le développement d’une solution importante…)

……. Features > (Une feature est un service qui répond à l’exigence d’une partie prenante – Business ou Enabler)>

……………………….. Story > (Les Stories sont des descriptions courtes des fonctionnalités souhaitées, écrites dans la langue de l’utilisateur. User Story ou Enable Story. Stories implémentées ensuite via des tâches de développement et de test)

C’est donc un niveau supplémentaire par rapport au modèle générique ; un système à 3 niveaux qui peut s’avérer sur dimensionner par rapport à nos contextes de travail (d’autant que les EPICS doivent être reliés à des éléments stratégiques supérieurs de plus haut niveau, type Objectifs stratégiques annuels issus d’une approche OKR) et qui n’est pas sans poser problème dans certains outils de gestion de backlog. Jira ne gère par exemple que les niveaux Epics et Stories, et pas un troisième niveau Feature…

Contexte #3 : Business Agility ou Change, c’est à dire l’agilité Hors IT

Il s’agit de contextes émergents dont j’ai fait ma spécialité (et qui reprend les éléments de base du contexte 1 quand il s’agit d’utiliser le concept d’epic).

L’EPIC est une grande initiative de changement qui apporte de la valeur à un bénéficiaire précis.

L’EPIC est vue comme une User Story de grande taille, estimée trop grosse pour entrer et être terminée dans un sprint (de plusieurs semaines). Une epic est ainsi décomposée en des stories plus petites.

L’interêt de l’agilité pour une meilleure performance de l’entreprise est grandissant et l’agilité du métier de l’entreprise s’inscrit aujourd’hui comme une évidence. Au delà d’une collaboration de plus en plus fine des métiers avec l’IT (via les rôles de Product Owner ou de Product Manager), les équipes métiers (en particulier Marketing et Ressources Humaines) adoptent les pratiques agiles dans leur quotidien : le découpage de grands projets ou grands sujets métier en de petites unités sources de valeur est l’une d’entre elles. Même si les sprints sont un peu plus longs notamment côté RH où je préconise encore bien souvent des sprints d’1 mois, EPICS et USER STORIES apparaissent immédiatement comme des unités utilisables par les métiers sur la base d’un modèle simple en deux niveaux. Epics et user stories ont alors des templates, des hypothèses de valeur et des critères d’acceptation associés.

Côté Change, le constat est tout aussi juste. Le postulat de base est de vivre les grands programmes de transformation comme des projets agile et comme des séries d’experimentations en livrant régulièrement des incréments de changement et en embarquant un maximum de personnes et équipes. Pour plus d’informations, vous pouvez vous référer à mes livres « Culture Agile » (2018) et « Agile Culture » (2019) qui décrivent la marche à suivre. Là encore, les unités Epics & Stories (regroupés en thèmes de transformation) apparaissent comme des éléments incontournables dans ces grandes saisons de transformation…

Je m’appelle Jean Claude GROSJEAN. J’éveille les personnes, les équipes et les entreprises à l’agilité et les accompagne dans leur transformation. Je travaille à Paris et Genève. N’hésitez pas à me contacter!

Qui suis-je ? En quoi puis-je vous aider ?

Coach agile d’entreprise, coach professionnel (HEC Paris), formateur et professeur à HEC Lausanne, je suis le fondateur du cabinet Eveil Agile et l’auteur des livres « Culture Agile » (2018) et « Revolution RH Agile » (2020). Ce blog « qualitystreet.fr » est désormais une référence reconnue sur l’agilité, le coaching agile et la facilitation.

Depuis plus de 15 ans, je me suis spécialisé dans la transformation agile d’entreprise (de toute taille et de tout secteur d’activité : LUXE, FINANCE, INDUSTRIE, TELECOM, MÉDIAS, RETAIL…), le conseil RH agile et la mise en place d’organisations orientées Produit. Je travaille pour l’essentiel à PARIS, GENEVE et LAUSANNE mais reste ouvert à toute proposition.