L’Epic Agile est souvent présentée comme un bloc fonctionnel d’un produit digital, rassemblant en son sein plusieurs user stories. Elle synthétise les besoins de l’utilisateur, identifiés au cours de l’élaboration de la Roadmap produit, dans le Backlog Produit. L’Epic est souvent utilisée à des fins d’organisation de la production. Mais est-ce son unique intérêt ? Voyons cela ensemble !
Note : la définition et les usages de l’Epic diffèrent selon la méthode Agile envisagée. Le propos de cet article se concentrera sur l’Epic de la méthode Agile Scrum. C’est en effet le framework que nous utilisons principalement chez Kanbios.
Qu’est-ce qu’une Epic ? Une « grosse user story » ? Un conteneur de user stories ? Une catégorie dans un Backlog ?
La définition de l’Epic (ou épopée) peut varier d’une méthode Agile à une autre. De même que d’une équipe à une autre. Pour faire simple, une Epic est la traduction d’un besoin utilisateur identifié dans la Roadmap produit dans un Backlog Produit. Elle décrit une fonctionnalité ou un groupe fonctionnel de votre produit digital qui va répondre au besoin spécifié. Elle contient suffisamment d’informations pour permettre aux parties prenantes :
- de comprendre la valeur ajoutée du bloc fonctionnel pour l’utilisateur,
- d’estimer l’importance de ce bloc fonctionnel par rapport aux autres et de les hiérarchiser en vue de la planification des développements,
- d’évaluer la complexité du produit digital à développer en proposant un vision macroscopique du projet.
Les Epics structurent un Backlog produit. Pour autant, ce ne sont ni des catégories, ni des conteneurs dans lesquels on réunit plusieurs user stories participant au développement d’une même fonctionnalité. Il faut plutôt les considérer comme une user story en maturation.
En effet, au fur et à mesure de l’avancée du projet, le besoin exprimé dans la Roadmap produit va se préciser. Par conséquent, l’Epic Agile correspondant à ce besoin va, elle aussi, s’affiner. Cette maturation va donner lieu soit à un découpage de l’Epic en plusieurs user stories. Soit à une redéfinition de l’Epic en simple user story si le besoin fonctionnel a été initialement surestimé.
Par exemple, dans le cadre d’un projet d’application e-commerce, l’Epic « gestion du panier client » sera découpée en plusieurs user stories de type « ajout/suppression d’un élément au panier », « calcul du coût total du panier », « ajout de code promotionnel »…
Qui rédige les Epics ?
Comme pour les user stories, la rédaction des Epics d’un projet est un travail d’équipe. Le Product Owner (ou le Product manager) rédige l’essentiel d’une Epic en tant que responsable du Backlog Produit. Le Product Designer, le Lead Developer interviennent ensuite pour ajuster les requis design et techniques.
Quel est le lien entre l’Epic et l’Epic Burndown chart ?
Selon l’outil de gestion Agile que vous utilisez, Il est possible de suivre l’avancement des développements de l’application à une échelle macroscopique, grâce aux Epics. On représente cette progression sous la forme d’un graphique : l’Epic Burndown chart.
L’Epic Burndown chart matérialise l’avancée de la production de chaque Epic du Product Backlog. Pour faire simple, à chaque fois qu’une user story associée à une Epic est clôturée, l’Epic Burndown chart diminue. Cette représentation graphique est un outil de communication efficace pour entretenir la motivation des équipes de production et montrer l’évolution du projet aux commanditaires.
Attention : ne confondez pas l’Epic Burndown chart et le Sprint Burndown chart. Ce dernier montre l’avancement d’un Sprint, tout en fonctionnant sensiblement de la même façon que l’Epic Burndown chart.
Comment rédiger une Epic ?
Une Epic bien rédigée permet à toutes les parties prenantes de comprendre l’intérêt de la fonctionnalité (ou du bloc fonctionnel) pour l’utilisateur, et de définir un cadre de travail pour l’équipe de production. L’idée est de donner suffisamment d’éléments pour que l’équipe de production puisse proposer une solution de développement acceptable et définir les user stories de cette solution avec le Product Owner. Il existe 4 aspects à ne pas négliger lors de la rédaction d’une Epic. Nous les avons résumés ci-dessous.
1. Nommer clairement l’Epic
L’intitulé de l’Epic doit être unique, clair, concis et ne pas susciter de malentendus parmi les parties prenantes. Souvent, le nom de l’Epic permet d’en clarifier les objectifs de la fonctionnalité.
Exemple : ajouter un produit au panier, accéder à l’annuaire des employés, créer un compte utilisateur.
2. Rédiger l’introduction (ou la description) de l’Epic
L’introduction (ou la description) explique à quoi va servir le bloc fonctionnel et ce qu’on souhaite atteindre à travers cet Epic. Sa rédaction suit souvent selon ce modèle :
- Qui ? (utilisateur cible)
- Quoi ? (l’objectif à atteindre)
- Pourquoi (la valeur ajoutée)
On complète souvent cette courte description par des informations issues de la phase de Discovery qui contextualisent la demande et permettent d’en comprendre l’intérêt : les raisons de la création de la fonctionnalité, des KPIs à améliorer, des informations sur les utilisateurs… Selon les besoins et la complexité du projet, il est également possible d’ajouter de la documentation additionnelle à l’Epic (plan marketing, contraintes légales, parcours utilisateur…). Cela permet à l’équipe de production d’anticiper des contraintes de production, ou des points qui peuvent invalider leurs propositions.
Exemple : Cette fonctionnalité permettra aux utilisateurs d’intéragir avec le créateur de contenus et les autres participants à la session de streaming, afin de vivre une expérience plus engageante.
- En tant qu’utilisateur, je veux pouvoir poser des questions en direct au créateur de contenus, exprimer mon approbation (ou non) et réagir aux commentaires des autres participants.
- En tant que créateur de contenus, je souhaite connaître l’opinion des participants, réagir à leurs propos au cours du live et modérer les discussions.
- Idéalement, il doit être possible pour le créateur de contenus de bannir du live un participant en un clic. En effet, la plateforme a une politique stricte en matière de harcèlement et de répression de propos discriminatoires et s’engage à développer un espace d’expression libre et sécurisé pour tous.
3. Délimiter le périmètre de l’Epic
Il s’agit de décrire les limites d’application de l’Epic, afin de cadrer les actions de l’équipe de production et faciliter l’estimation de leur charge de travail.
Exemple : Le banissement d’un participant d’un live ne peut être opéré que par le créateur de contenus et pour la durée du live. Les échanges entre les participants au cours du live ne sont pas conservés.
4. Définir les critères d’acceptation de l’Epic
Comme les user stories, les Epics ont également leur propre Definition of done, ou critères d’acceptation. Ces critères doivent rester suffisamment génériques pour ne pas influencer les propositions de production. Ils spécifient notamment les requis produit, techniques et design. Et surtout, ils doivent faire consensus auprès de toutes les parties prenantes.
Pour résumer
- Une Epic Agile décrit dans le Backlog produit un bloc fonctionnel ou une fonctionnalité à développer afin de répondre à un besoin utilisateur.
- Ensuite, l’Epic évolue au cours des avancées du projet à mesure que le besoin utilisateur se précise. En effet, elle peut être découpée en user stories ou bien redéfinie en user story.
- Une Epic est composée d’un titre explicite, une courte description, d’un périmètre, de critères d’acceptation ainsi que toute information utile pour sa compréhension et son estimation.
Envie d’aller plus loin ?
Vous avez rédigé les Epics de votre futur produit digital ? Passez à présent à l’étape suivante en rédigeant des user stories, qui vont apporter de la valeur ajoutée à votre projet ! Pour en savoir plus à ce sujet, rendez-vous sur cet article.
Et si vous souhaitez bénéficier d’un accompagnement personnalisé pour construire votre produit digital, prenez rendez-vous avec nos experts en complétant ce formulaire !
