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.
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 :
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 »…
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.
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.
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.
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.
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 :
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.
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.
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.
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 !