Comment découper vos Epic Stories et vos User Stories ?

Lors de la présentation des nouvelles demandes clients par le "Product Owner" à l'équipe de développement durant le rituel du "Backlog Refinement", l'équipe Scrum doit décider par rapport à la taille de ces demandes, si un découpage s'avère nécessaire ou pas, sachant q'une User Story doit avoir une taille qui va lui permettre d'être traitée entièrement dans un seul "Sprint", et pas sur plusieurs.

On parle d'un "Epic" ou autrement dit "Epic Story" quand la taille de la demande ou la fonctionnalité est assez importante, il s'agit d'un ensemble de sous-fonctionnalités à développer et réaliser, et qui sont regroupées ensemble. Dans ce cas de figure l'équipe Scrum doit décider un découpage qui peut prendre plusieurs types, et c'est comme à partir de ça que le Product Backlog est organisé (Thèmes / Features / Epics / User Stories).

Une bonne User Story doit impérativement respecter le modèle "INVEST" (Indépendante, Négociable, de Valeur, Estimable, Small, et Testable), du coup si on pense au cinquième critère (Small : de petite taille), on doit alors envisager un découpage des fonctionnalités et demandes de grande tailles afin d'avoir des petites User Stories fines maîtrisables à faire embarquer dans des différents "Sprints", sans oublier et faire attention à la valeur métier et quand est ce qu'elle va être exploitable par l'utilisateur final.

Il existe 3 types principaux de découpage des "Epic Stories", à savoir :

• Découpage Horizontal :

C'est le découpage le moins conseillé et recommandé par les Coach agiles, vu qu'on va effectuer un découpage isolant et traitent chaque couche de l'architecture à part (Composant architectural), du coup on ne peut avoir de la valeur métier qu'à partir de la dernière livraison, et le client ne pourra pas tirer de bénéfice avant.

Exemples :

• Livrer dans un incrément produit que des écrans (IHM) statiques (Interfaces Utilisateur) .

• Livrer dans un incrément produit que l'ensemble des requêtes SQL permettant la connexion à la base de données et la récupération des données.

• Livrer dans un incrément produit que des services Back-end ou Front-end.

• Découpage Vertical :

C'est un découpage recommandé par les agilistes vu qu'elle présente plusieurs avantages, en occurrence le faite d'avoir à chaque fin d'un Sprint un incrément produit exploitable donnant une partie du logiciel démontrable devant les parties prenantes, et qui ajoute de la valeur métier à chaque fois d'une façon incrémentale. Aussi bien grâce à ce type de découpage on va réduire les dépendances et améliorer la capacité de l’équipe Scrum qui va lui permettre de livrer potentiellement et fréquemment des fonctionnalités utilisables à chaque fin d'un Sprint.

• Découpage par décomposition du comportement du système :

Ce type de décomposition à partir d'exemples est le plus recommandé dans les projets agiles, il s'inspire de la pratique BDD (Behavior Driven Development) qui permet d'identifier et étudier le comportement du système attendu d'une ou plusieurs fonctionnalités, du coup l'équipe Scrum va viser à travers ce type de découpage le regroupement de plusieurs scénarios dans des Users Stories, mais cela nécessite une grande maîtrise du domaine fonctionnel.

Conclusion :

Il existe autres stratégies de décomposition et découpage des User Stories que je vais les détailler dans des prochains articles (Par scénarios, par cheminement des étapes du Workflow, par type d'opérations, par type de données, par type d'utilisateurs ou personna, ...Etc.), mais l'objectif c'est toujours d'avoir des User stories très fines et maitrisables, permettant de recevoir de la valeur métier à chaque fin d'un Sprint.

Il est nécessaire de prendre en considération toujours la faisabilité technique lors de découpage des User Stories par l'équipe Scrum, car c'est important de respecter la faisabilité technique remontée par l'équipe de développement vu que c'est elle qui va réaliser le travail.