Lors de la gestion d’un projet informatique avec la méthodologie Scrum, le développement est réalisé en mode itératif, durant des sprints de quelques semaines. Les termes « agile epic » ou « epic story », et « user story » reviennent souvent. Ils recouvrent des concepts différents, liés aux spécifications fonctionnelles, et donc particulièrement structurants pour le projet. Essayons maintenant de décrire plus précisément à quoi correspondent ces éléments agiles.
Des spécifications au travers des user stories
Les spécifications sont particulièrement importantes dans un projet de développement informatique, car elles conditionnent la compréhension des besoins clients par l’équipe technique et la réalisation des fonctionnalités décrites.
Des spécifications incomplètes, mal écrites ou peu claires, peuvent conduire tout droit à l’échec du projet. L’incompréhension du besoin ou une mauvaise interprétation des spécifications peuvent conduire au développement de fonctionnalités contradictoires ou ne correspondant pas aux souhaits du client ou des utilisateurs finaux.
Dans un projet Scrum, les fonctionnalités sont rédigées au fur et à mesure des sprints. On ne détaille une fonctionnalité que si celle-ci doit être réalisée dans le prochain sprint. De cette façon, il est possible de profiter de l’expérience déjà acquise lors des sprints précédents, mais également de s’adapter beaucoup plus facilement et rapidement à des demandes de modifications ou à des changements de priorité des clients.
En Scrum, les spécifications fonctionnelles sont rédigées sous la forme de user stories. Une user story est une description simple d’une fonctionnalité. Elle est écrite de façon à être compréhensible par l’ensemble des intervenants, du product owner au développeur.
Pour s’assurer qu’une user story correspond bien à la description et à la définition du besoin, elle est structurée en trois parties (les « 3C »), de la façon suivante :
- La carte : la description du besoin, la priorité de réalisation, une estimation du coût de son développement et des tests, ainsi que les critères d’acceptation.
- La conversation : les échanges entre le product owner et l’équipe afin d’identifier et de négocier les détails.
- La confirmation : les tests fonctionnels qui permettront de déterminer quand la user story sera terminée.
Des users stories de qualité, rédigées à l’aide de la méthode INVEST (Indépendante, Négociable, apportant une Valeur ajoutée, Estimable, Suffisamment petite et Testable), vont permettre de décrire de petites fonctionnalités de façon détaillée.
Le problème avec cette approche des user stories, c’est que toutes les fonctionnalités sont indépendantes. Si l’on considère uniquement les user stories en tant que telles, leur priorisation et leur développement risquent d’être compliqués, notamment au niveau du suivi du projet.
Le regroupement de plusieurs user stories au sein d’une agile epic story va permettre de clarifier l’organisation des fonctionnalités et de faciliter l’organisation de leurs développements.
Scrum epic story ?
On pourrait définir la scrum epic story comme une macro-fonctionnalité, un regroupement de plusieurs fonctionnalités du système à développer.
Les epic stories vont donc être définies dès le début du projet. Il s’agit dans un premier temps de définir ces macro-fonctionnalités sans entrer dans les détails, ni définir une quelconque priorité de réalisation. « Gestion du panier client », « Gestion de l’utilisateur » ou encore « Gestion du catalogue » sont autant d’exemples de scrum epic stories possibles.
Une epic story est donc une description fonctionnelle de haut niveau de l’application à développer.
Lorsque le product owner identifie un besoin pour l’application, ce dernier va être matérialisé par une epic. Elle contiendra une description sommaire ainsi qu’une macro évaluation de son coût de réalisation.
L’ensemble de ces epic stories va permettre d’obtenir une évaluation de la complexité de l’application à réaliser. L’évaluation de chaque epic story va également permettre de définir les priorités.
L’epic story va être rédigée par le product owner. Une fois créée, elle va pouvoir être détaillée à l’aide de user stories. Chaque user story va permettre de décrire une fonctionnalité contenue dans l’epic story.
Naturellement, une epic story, qui peut potentiellement contenir un nombre important de fonctionnalités, et donc de user stories, ne pourra sans doute pas être réalisée entièrement durant un seul sprint. Les développements liés à une scrum epic seront donc répartis sur plusieurs sprints consécutifs. Les spécifications, contenues dans les user stories seront rédigées de façon détaillée au fur et à mesure des sprints, et l’epic sera donc susceptible d’évoluer au fur et à mesure du projet.
Avec l’approche des epic stories, il est possible de suivre l’avancement des développements de l’application à une échelle macroscopique. C’est en effet plus facile avec une epic story, notamment lorsque les différentes user stories sont réparties entre plusieurs équipes de développement. Les remontées d’information des différents suivis de réalisation des user stories vont être regroupées pour fournir une vision globale de l’avancement de l’epic au fur et à mesure des sprints du projet.
Pour conclure sur l’agile epic story
L’agile epic story, en regroupant les fonctionnalités d’une application décrites sous la forme de user stories, va fournir une vue macroscopique de la progression des développements. Cette organisation va permettre d’une part de visualiser la complexité d’un projet dans son ensemble, et d’autre part de réduire la complexité de la gestion de la réalisation de l’application. Le suivi des développements au fur et à mesure des sprints s’en trouve simplifié.
Nutcache, solution complète de gestion de projet scrum en ligne, propose tous les outils nécessaires à la création de scrum epic stories et au suivi de leur réalisation. Inscrivez-vous dès maintenant et profitez de 14 jours d’essai gratuits.
