Epics Agile : définition, exemples et modèles

Lorsque vous adoptez Agile et DevOps, les epics servent à gérer les tâches. Il s'agit de corpus de tâches qui peuvent être subdivisées en tâches spécifiques (appelées « stories » ou « user stories ») basées sur les besoins/demandes de clients ou d'utilisateurs finaux. Un modèle de suivi des tâches permet aux équipes d'organiser, de hiérarchiser et de suivre leurs tâches de manière efficace.

Les epics sont un moyen utile d'organiser votre travail et de créer une hiérarchie. L'idée est de diviser le travail en plus petits livrables, de sorte à pouvoir réaliser de grands projets et à continuer de livrer de la valeur à vos clients sur une base régulière. Les epics aident les équipes à décomposer leur travail, tout en continuant à poursuivre un objectif plus important.

Maintenir l'agilité dans l'organisation de grandes tâches, comme les epics, n'est pas une mince affaire. Connaître la relation entre les epics et les bonnes pratiques Agile et DevOps saines est une compétence essentielle, quelle que soit la taille de votre organisation.

Une epic est un vaste corpus de tâches qui peuvent être subdivisées en plus petites stories, parfois appelées « Tickets » dans Jira. Les epics englobent souvent plusieurs équipes, sur plusieurs projets, et peuvent même être suivies sur plusieurs tableaux.

La livraison des epics couvre pratiquement toujours une série de sprints. Au fur et à mesure que l'équipe approfondit ses connaissances sur une epic grâce au développement et au feedback des clients, des user stories seront ajoutées et supprimées, si nécessaire. C'est la clé avec les epics Agile : le périmètre est flexible, en fonction du feedback du client et de la cadence de l'équipe.

Imaginons que nous sommes en 2050 et que nous travaillons pour une agence organisant des voyages spatiaux récréatifs. Nous faisons environ une dizaine de lancements par an, aucun d'eux n'est donc le plus grand projet de l'année, mais chaque lancement est loin d'être routinier et nécessitera donc de nombreuses heures-personnes. Cette configuration est parfaite pour une epic.

Un exemple d'epic, « Lancement du tourisme spatial, mars 2050 » inclut des stories pour des tâches de routine, ainsi que des stories visant à améliorer les aspects clés du lancement de la navette : de l'achat de billets de voyage spatial au lancement de la navette lui-même. Ainsi, plusieurs équipes contribueront à cette epic en travaillant sur un large éventail de stories.

L'équipe de développement prenant en charge l'achat des billets pour le lancement de mars 2050 pourrait structurer son epic comme suit :

Simultanément, les équipes de propulsion pourraient contribuer à la même epic avec ces stories :

Une epic devrait fournir à l'équipe de développement tout ce dont elle a besoin pour réussir. D'un point de vue pratique, il s'agit de l'échelon le plus élevé de sa hiérarchie professionnelle. Toutefois, comprendre comment une epic se rapporte à d'autres structures Agile fournit un contexte important pour le développement quotidien.

• Une feuille de route produit est un plan d'action décrivant l'évolution d'un produit ou d'une solution dans le temps.
• Un thème est un objectif organisationnel axé sur la création d'epics et d'initiatives.
• La feuille de route produit est exprimée et visualisée comme un ensemble d'initiatives tracé autour d'un calendrier.
• Diviser des initiatives en epics aide à maintenir la relation entre le travail quotidien de l'équipe (exprimé sous forme de petites stories) et les objectifs métier globaux.

Un ensemble d'epics achevées est axé sur une initiative spécifique, qui maintient le développement et l'évolution du produit dans son ensemble avec les exigences du marché et des clients en plus des thèmes organisationnels.

Dans notre exemple ci-dessus, un thème serait l'augmentation du nombre de lancements de navettes spatiales, la feuille de route viserait à faire passer le nombre de lancements de 3 par trimestre à 4, les initiatives viseraient à réduire les coûts et à augmenter les ventes de billets, et chaque epic serait intégrée dans les initiatives.

Lorsque vous créez une epic, prenez en compte les autres outils de planification et d'organisation que votre équipe a peut-être déjà mis en place. Créer des epics autour des objectifs trimestriels d'une équipe ou des OKR est un bon début. Lors de la création d'une epic, tenez compte des points suivants :

• Rapports : créez des epics pour les projets que les responsables et les dirigeants voudront surveiller.
• Storytelling : utilisez des epics, et les stories qui s'y trouvent, comme outil pour expliquer comment vous êtes arrivé à l'état actuel d'une fonctionnalité ou d'un produit.
• Culture : laissez la culture organisationnelle dicter la taille et la granularité d'une epic.
• Durée : la plupart des équipes de développement s'appuient sur des frameworks d'estimation et non sur la durée, mais cette vérification instinctive est valable pour vous assurer que vos epics seront terminées en quelques semaines. La durée ne doit être ni trop longue, ni trop courte.

Découvrez comment fonctionnent les epics dans Jira.

Diviser une epic en stories plus pratiques permet de mieux comprendre un projet et d'entretenir la dynamique, mais c'est une tâche qui peut se révéler fastidieuse pour les non-initiés. Il n'existe pas de solution universelle pour créer des stories à partir d'une epic, mais vous pouvez prendre en compte beaucoup de bonnes options :

• Rôle utilisateur ou persona : créez une story unique pour chaque persona. « Connexion plus rapide pour les nouveaux visiteurs », « Connexion plus rapide pour les clients qui reviennent », etc.
• Étapes ordonnées : divisez le processus et créez une story pour chaque étape.
• Culture : laissez les normes de l'équipe déterminer si une story est une tâche rapide ou un projet d'une semaine.
• Durée : sauf convention contraire, concevez des stories qui peuvent être terminées en un seul sprint ou moins.

Il n'existe pas de définition universelle qui délimite une grande story d'une epic. En général, tout périmètre de travail dont l'équipe évalue la réalisation en « semaines » (ou plus) plutôt qu'en « heures » ou en « jours » devrait être considéré comme une epic et divisé en petites stories.

Les graphiques Burndown servent également à visualiser les epics et à garder les équipes motivées et les responsables informés. Un bon graphique Burndown d'epic met réellement en avant l'agilité de l'organisation.

Un graphique Burndown d'epic présente la quantité de travail estimée et réelle pour un sprint ou une epic. L'axe horizontal (x) d'un graphique Burndown indique le temps, tandis que l'axe vertical (y) indique les stories ou les tickets.

Utilisez un graphique Burndown pour suivre l'ensemble du travail restant et pour déterminer la probabilité d'atteindre l'objectif du sprint. En suivant le travail restant tout au long de l'itération, une équipe peut gérer son avancement et réagir en conséquence.

La surveillance d'un graphique Burndown permet clairement de suivre l'avancement de l'équipe, ainsi que les bloqueurs auxquels elle est confrontée. Une telle visibilité permet de synchroniser tout le monde et encourage à tenir une discussion ouverte sur l'évolution du produit et les prévisions d'achèvement. Sans parler du fait que la transparence est un gage de confiance !

Découvrez comment configurer les graphiques Burndown dans Jira

Une fois l'art de la création d'epics et de stories maîtrisé, vous voudrez peut-être aller plus loin et optimiser vos processus à l'aide de l'automatisation. Voici les trois règles d'automatisation les plus courantes utilisées pour les sprints dans Jira.

1. Ajouter automatiquement trois stories lors de la création d'une epic. Accéder à la règle.
2. Fermer automatiquement les stories lorsqu'une epic est marquée comme terminée. Accéder à la règle.
3. Modifier l'état d'une epic lorsque l'état d'un des tickets liés est modifié. Accéder à la règle.

Découvrez ces règles d'automatisation et une centaine d'autres dans la bibliothèque de modèles Jira Automation.

Accéder à la bibliothèque

Les epics ne sont pas le fondement absolu d'un programme Agile, mais ils sont les moteurs pratiques pour la plupart des équipes Agile et DevOps. Comprendre où elles s'intègrent dans un programme Agile sain contextualise votre travail, tandis que les diviser en stories crée une dynamique.