Respecter une petite taille pour vos User Stories est une bonne pratique qui favorise l’approche itérative et incrémentale, permet des feedbacks rapides et accélère votre flux de travail.
La maîtrise des 12 techniques de découpage pour vos User Stories est par conséquent indispensable pour vos Product Owners.
Dans cet article, nous vous proposons d’explorer ces 12 techniques, illustrées par des exemples.
Le but est de faciliter l’apprentissage et permettre une application concrète dans vos contextes.
Philosophie d’approche
Chaque User Story peut en général se décomposer en une User Story cœur représentant le service minimum viable, et des User Stories complémentaires pour enrichir ce service, itération après itération.
Ce principe de décomposition s’inscrit pleinement dans l’approche Scrum, où chaque itération permet de livrer une version incrémentale du produit.
Les techniques de découpage ne sont donc pas utilisées uniquement pour les User Stories trop grosses.
Chercher systématiquement le minimum viable pour chaque User Story est un véritable état d’esprit.
C'est essentiel pour accélérer le flux de travail, et doit être un réflexe pour vos Product Owners.
La User Story cœur est évidemment la plus prioritaire, car son objectif est d’apporter un premier niveau de service le plus rapidement possible.
Les User Stories complémentaires doivent être priorisées.
Pour cela, le retour sur investissement (rapport entre valeur et complexité) est un bon indicateur, au même titre que la criticité temporelle et le niveau de risque.
1) Les critères à respecter pour chaque User Story du découpage
Les User Stories issues du découpage doivent respecter les critères habituels :
1.1) I – Independent
Les User Stories doivent être indépendantes les unes des autres sous peine d’introduire un ordonnancement figé, contraire à notre volonté de reprioriser en permanence.
1.2) N – Negociable
Une User Story est une base de discussion et pas un contrat figé.
Un échange constructif entre le PO et les développeurs, peut aboutir à une User Story beaucoup plus simple à implémenter pour une valeur métier identique.
Le découpage doit donc toujours être réalisé avec votre équipe.
1.3) V – Valuable
Une User Story apporte de la valeur aux utilisateurs.
« Pour qui apportons-nous de la valeur ? » est une question importante à se poser.
Chaque User Story issue du découpage doit donc également apporter de la valeur.
1.4) E – Estimable
La complexité de la User Story peut être estimée.
Au-delà de l’estimation, il s’agit de vérifier que le travail à faire est compris par tous.
Une User Story trop complexe entraîne un risque sur la fiabilité de son estimation.
Il est donc préférable de la redécouper.
1.5) S – Small
Une User Story doit être faisable en une itération.
Les techniques de découpage doivent être utilisées jusqu’à ce que toutes les User Stories candidates à la prochaine itération soient suffisamment petites.
La taille préconisée se situe entre 1/10ᵉ et 1/6ᵉ de la vélocité de l’équipe.
1.6) T – Testable
Une User Story doit contenir des critères d’acceptation permettant de démontrer que le travail a été réalisé correctement.
Chaque User Story issue du découpage doit donc également posséder des critères d’acceptation.
Modèle des spécifications Agiles (+25 Templates)
Structurez vos infos en user stories
Les 12 techniques de découpage
1) Étapes de workflow
Si votre User Story décrit un workflow en plusieurs étapes, vous pouvez la découper selon ces étapes.
Vous commencez par implémenter la première étape et la dernière étape, car elles sont indispensables pour garantir un workflow de valeur.
Ensuite, procédez à l’implémentation des étapes intermédiaires par ordre de priorité.
Exemple
US #1 : En tant qu’éditeur, je peux publier un article sur le blog.
Découpage réalisé
Commentaires
L’US #1.1 est prioritaire et représente le workflow minimal, incluant la première et la dernière étape.
L’US #1.2 (revue juridique) est mise en place avant l’US #1.3 (revue éditoriale), bien que cela ne corresponde pas à l’ordre logique du workflow.
Cela s’explique par son caractère réglementaire, qui impose son traitement en priorité.
2) Variations des règles métiers
Si votre User Story décrit plusieurs règles fonctionnelles, vous pouvez la découper selon ces règles puis ordonnancer les User Stories obtenues en fonction de l’importance de ces règles.
Exemple
US #2 : En tant que voyageur, je peux rechercher un vol avec des dates flexibles.
Découpage réalisé
Commentaires
L’US #2.1 permet bien de rendre le service minimal attendu.
Les US #2.2 et #2.3 viennent ensuite enrichir l’expérience utilisateur de manière itérative et incrémentale.
3) Effort principal
Si votre User Story nécessite en prérequis une nouvelle capacité technique que vous n’avez pas encore, vous pouvez implémenter d’abord cette capacité en y associant une fonctionnalité simple.
Enrichissez par la suite le service rendu avec d’autres User Stories qui utiliseront cette même capacité.
Exemple
US #3 : En tant qu’acheteur, je peux payer mon billet avec une carte de crédit.
Découpage réalisé
Commentaires
La capacité technique seule ne peut pas être considérée comme une User Story, car elle ne respecterait pas le critère « V – Valuable ».
Nous lui associons donc le type de carte VISA, prioritaire pour nous, afin de lui donner de la valeur.
Un sondage auprès de vos clients, peut aider à classer les types de cartes utilisées afin de prioriser au mieux vos User Stories.
4) Simple / Complexe
Si votre User Story comporte une partie simple qui apporte le maximum de valeur, découpez en implémentant d’abord la partie simple.
Exemple
US #4 : En tant que voyageur, je peux rechercher un vol en précisant le nombre d’escales et les compagnies.
Découpage réalisé
Commentaires
Vous noterez ici la complexité croissante des différentes User Stories.
D’où l’importance d’embarquer les développeurs en séances de découpages, pour ne pas passer du temps à rédiger des User Stories beaucoup trop complexes au regard de la valeur métier escomptée.
5) Variations des données
Si votre User Story a le même comportement pour différents types de données, vous pouvez découper par type de données et commencez par le type de données le plus important.
Exemple
US #5 : En tant que voyageur, je peux réserver une chambre d’hôtel.
Découpage réalisé
Commentaires
Dès la première User Story (Français), donnez de la visibilité à vos développeurs sur les langues prévues par la suite.
Ainsi, ils pourront bien prendre en compte le caractère multilingue de l’application.
Cela a beaucoup d’importance sur les choix d’implémentation.
Là encore, une étude de marché auprès de vos clients potentiels, vous permettra de prioriser les langues plébiscitées.
6) Variations d’interfaces
Si votre User Story comporte une interface complexe, vous pouvez commencer par une version simple que vous enrichirez par la suite.
Exemple
US #6 : En tant que client bancaire, je peux rechercher des opérations sur mon compte courant entre 2 dates.
Découpage réalisé
Commentaires
Si vos développeurs utilisent déjà le composant calendrier et que cela est sans impact sur la complexité, ne découpez pas !
Notez, là encore, l’importance d’un dialogue systématique avec vos développeurs.
7) Performance en deux temps
Si votre User Story possède une exigence non fonctionnelle liée à la performance, vous pouvez satisfaire en premier le côté fonctionnel et intégrer plus tard l’aspect performance.
Exemple
US #7 : En tant que voyageur, je peux lancer une recherche de vols entre deux destinations.
Découpage réalisé
Commentaires
Différer l’aspect performance pour recueillir des feedbacks rapides est intéressant, mais dans ce cas, préférez un public restreint (exemple : friends & family).
Activez le service plus largement, uniquement lorsque les exigences de performance sont atteintes.
Communiquez à vos développeurs, dès le départ, le niveau de performance attendu afin que le codage du service dégradé ne soit pas entièrement à revoir par la suite.
8) Opérations
Si votre User Story inclut de multiples opérations, vous pouvez écrire une User Story dédiée à chaque opération.
Exemple
US #8 : En tant que sportif, je peux gérer mes activités.
Découpage réalisé
Commentaires
Cette technique de découpage introduit des dépendances entre les User Stories découpées.
Exemple : il n’est pas possible de supprimer une activité, si elle n’a pas été préalablement créée.
Demandez donc à vos développeurs, si le fait de dissocier les opérations (création, modification, suppression) a du sens et n’ajoute pas de complexité.
9) Rôles utilisateur
Si votre User Story implique plusieurs rôles, vous pouvez la découper pour n’avoir qu’un rôle par User Story.
Exemple
US #9 : En tant qu’utilisateur, je peux gérer des congés en fonction de mon rôle.
Découpage réalisé
Commentaires
La gestion des rôles utilisateurs et des droits associés est une réflexion à mener en amont des itérations.
Apporter ces éléments tardivement dans le projet et de manière itérative et incrémentale, peut augmenter fortement la complexité de réalisation.
10) Cas droit / Cas d’erreurs
Si votre User Story contient une gestion d’erreurs, vous pouvez écrire une User Story pour le cas droit et ensuite ajouter des User Stories pour traiter les cas d’erreurs.
Exemple
US #10 : En tant que client, je peux me connecter sur le site afin d’avoir accès à un contenu sécurisé.
Découpage réalisé
Commentaires
Au même titre que la gestion des rôles utilisateurs, la gestion des erreurs est une réflexion à mener en amont des itérations.
Apporter ces éléments tardivement dans le projet et de manière itérative et incrémentale, peut augmenter fortement la complexité de réalisation.
11) Variations de plateformes
Si votre User Story a le même comportement sur plusieurs plateformes, vous pouvez découper par plateforme.
Exemple
US #11 : En tant que voyageur, je peux rechercher des vols entre deux destinations.
Découpage réalisé
Commentaires
Informez vos développeurs au plus tôt concernant vos exigences de plateformes et de navigateurs cibles.
Ces éléments ont un fort impact sur la complexité de réalisation.
12) Étude et implémentation
Si votre User Story est risquée ou comporte des incertitudes, vous pouvez rédiger une User Story dédiée à la réalisation d’un prototype, puis la compléter avec des User Stories d’industrialisation.
Exemple
US #12 : En tant que client bancaire, je peux ajouter un compte externe afin d’intégrer dans la gestion de mon budget, les opérations d’un compte d’une banque partenaire.
Découpage réalisé
Commentaires
Cette technique est à utiliser avec parcimonie, car bien que le prototype soit riche d’enseignements, il n’apporte pas de valeur métier directe à l’utilisateur.
Conclusion
Vous maîtrisez désormais 12 techniques de découpage pour vos User Stories.
Utilisez ces techniques en collaboration avec votre équipe, car vos développeurs vous donneront des feedbacks pertinents sur votre découpage.
Communiquez à vos développeurs les éléments structurants du projet au plus tôt.
Que ce soit plateformes cibles, exigences non fonctionnelles, gestion des erreurs, gestion des rôles, wireframes, charte graphique, ergonomie.
L’arrivée tardive de ces éléments peut engendrer d’importants surcoûts d’implémentation.
N’oubliez pas d’inclure dans vos User Stories la mise en place de métriques pour récolter des feedbacks rapides de tous types (nombre de nouveaux clients, nombre de clics sur une fonctionnalité…).
Et partagez-les avec votre équipe !
Enfin, lors de la présentation d’une User Story à votre équipe, resituez-la systématiquement dans le contexte global de l’application.
Ainsi, vous lui donnez du sens et facilitez sa compréhension par les développeurs.
Recevez GRATUITEMENT le Guide Pratique du Chef de Projet Performant
👉 Suivez une méthodologie claire pour gérer vos projets de bout en bout
👉 Améliorez votre efficacité opérationnelle en utilisant les bons livrables au bon moment
👉 Suivez 25 conseils d'expert et arrêtez de subir les dérives
Vous recevrez régulièrement des contenus intéressants. Vos données seront en lieu sûr, nous détestons le spam sans doute autant que vous, et vous pouvez vous désinscrire à tout moment. Voir notre politique de confidentialité.
