Découper les user stories : la méthode pour des sprints enfin terminés
Vos sprints se finissent avec beaucoup de travail « presque fini » ? Le découpage des user stories est le levier le plus sous-estimé pour livrer de la valeur, sprint après sprint.
En tant que coach agile, je vois la même scène se rejouer chaque semaine : une équipe Scrum termine son sprint, la revue arrive, et pourtant peu de choses sont réellement « Done ». Le back-end est prêt mais l’interface n’est pas branchée. Le flux principal fonctionne, mais les cas limites ne sont pas testés. La fonctionnalité est « proche », sans que personne n’ose la déclarer terminée.
Le coupable est presque toujours le même : des user stories trop grosses. Apprendre à découper les user stories n’est pas un détail technique de plus dans la boîte à outils du Product Owner, c’est ce qui sépare une équipe qui livre de la valeur d’une équipe qui reste éternellement à 90 %.
Pourquoi les grosses user stories sont un piège
Une user story trop grosse reste « en cours » pendant des jours, parfois tout le sprint. Elle crée une illusion de progrès : tout le monde est occupé, ça avance. Mais à la fin de l’itération, trop de travail est encore presque terminé.
C’est ce qu’on appelle le syndrome des 90 % : un logiciel est « fini à 90 % » pendant 90 % du planning. Pour un développeur comme pour le reste de l’équipe, impossible de prioriser correctement ce qui reste. Le problème n’est pas la malhonnêteté de l’équipe : c’est que le gros travail est difficile à mesurer tant qu’il est en cours. Nous sommes incapables de dire si une grosse story est à 60, 75 ou 90 %. En revanche, nous savons très bien dire si une petite story est terminée, oui ou non.
Règle pratique : un report occasionnel d’une story, c’est la malchance. Un report régulier, c’est un signal : regardez la taille de vos user stories. Méfiez-vous d’une story qui pourrait consommer la moitié ou plus de votre sprint.
Découpage de user story ≠ découpage en tâches techniques
Découper une user story, c’est la fractionner en stories plus petites qui représentent toujours un progrès porteur de sens vers un résultat. Ce résultat peut être : visible pour un utilisateur, utile au business, une réduction de risque, ou un apprentissage important pour l’équipe.
La distinction clé à garder en tête :
- Une tâche décrit une activité : « concevoir ceci », « coder cela », « tester cette partie ». C’est souvent le travail d’une seule personne.
- Une user story décrit un résultat : une capacité nouvelle pour l’utilisateur. Elle exige la collaboration de toute l’équipe de réalisation (développeurs, testeurs, designers) autour de l’analyse, du design, du développement, du test et du feedback. Un développeur seul ne « possède » pas une story.
Le test rapide : si l’énoncé décrit une seule activité réalisée par une personne, c’est probablement une tâche. S’il décrit une capacité, un résultat ou une étape d’apprentissage plus petits, ça peut être une bonne story.
L’erreur n°1 : découper par couche technique
La faute la plus fréquente est de découper une story par couche technique : UI / back-end / base de données / tests. Sur le tableau, chaque morceau paraît plus petit. Mais tout dépend de tout : rien ne peut être démontré tant que l’ensemble n’est pas assemblé. Vous n’avez pas découpé la valeur, vous avez juste éclaté la plomberie.
Mieux vaut découper verticalement : traverser toutes les couches nécessaires pour soutenir un résultat plus étroit, puis prioriser ces tranches. Prenons une story de recherche immobilière à découper.
|
❌ Découpage technique (à éviter)
• Construire l’interface de recherche |
✅ Découpage vertical par la valeur
• Rechercher par surface et nombre de pièces |
Chaque story verticale est démontrable seule. C’est tout l’enjeu : faire quelque chose de plus petit, mais qui a de la valeur.
Les 6 critères d’un bon découpage
Un bon découpage est « assez petit pour être fini, assez précieux pour compter, assez complet pour être testé ». Voici les six critères à vérifier sur chaque user story découpée :
1. Orientée résultat
Après coup, quelqu’un (utilisateur, système, business) peut faire quelque chose de nouveau.
2. Porteuse de valeur
Fonctionnalité, risque réduit ou hypothèse validée. Toute story n’a pas besoin d’être livrable seule.
3. Finissable
Elle tient confortablement dans un sprint, idéalement bien plus petite que ça.
4. Verticale
Elle traverse toutes les couches nécessaires à un résultat étroit, jamais une seule couche technique.
5. Claire et testable
Des critères d’acceptation vérifiables sans dépendre d’une autre story ; on décrit le comportement, pas l’implémentation.
6. Délibérément contrainte
On démarre par un persona, un chemin, une règle métier ou une plateforme. La contrainte doit être un choix, pas un oubli.
« Le chemin heureux d’abord » : un découpage par les cas
Une contrainte intentionnelle est un excellent angle pour découper. Imaginez une fonctionnalité de validation de congés où certains salariés ont besoin de l’accord de deux managers. Plutôt que d’attaquer le tout d’un bloc, vous pouvez la découper et prioriser ainsi :
- Première user story : gérer le cas normal d’un seul manager (le « chemin heureux »).
- Story suivante : traiter le cas limite des deux validations.
« Nous supportons d’abord le chemin heureux » est une décision utile. « Nous avons oublié les cas d’erreur » n’en est pas une. La nuance est toute là : la contrainte doit être choisie.
« Done » ne veut pas toujours dire « livré ». Une story est terminée quand elle est de qualité, bien testée, et fait bien ce qu’elle fait. Cela ne signifie pas que la fonctionnalité est assez cohérente pour être mise en production seule. Vous pouvez finir « Annuler » dans un sprint et « Rétablir » dans le suivant : « Annuler » est Done même si vous attendez de livrer les deux ensemble.
Où découper, concrètement, dans Scrum ?
Le découpage n’est pas une pratique isolée : il s’intègre dans le flux naturel de Scrum. Le moment privilégié est le backlog refinement (l’affinage du product backlog), où le Product Owner et l’équipe préparent les prochaines user stories. Une story qui arrive en sprint planning encore trop grosse n’a pas été suffisamment affinée.
Deux outils aident beaucoup le découpage :
- Le story mapping : il visualise le parcours utilisateur de gauche à droite et permet de découper horizontalement des tranches de valeur cohérentes plutôt qu’au hasard.
- La Definition of Done : elle fixe ce que « terminé » veut dire. Sans elle, on confond « codé » et « fini », et le syndrome des 90 % revient par la fenêtre. Chaque user story découpée doit pouvoir satisfaire la Definition of Done dans le sprint.
En tant que coach agile, ma recommandation : faites du découpage un réflexe d’équipe, pas une corvée du Product Owner. Les meilleures tranches émergent de la conversation entre développeurs, testeurs et PO autour des critères d’acceptation.
Questions fréquentes sur les user stories
Qu'est-ce qu'une user story en Scrum ?
Une user story est une formulation courte d’un besoin du point de vue de l’utilisateur, généralement sous la forme « En tant que… je veux… afin de… ». En Scrum, elle vit dans le product backlog, est affinée lors du backlog refinement, puis tirée dans un sprint. Contrairement à une tâche, elle décrit un résultat porteur de valeur, pas une activité technique isolée.
Qu'est-ce qu'une US ?
« US » est simplement l’abréviation de « user story ». Quand une équipe parle de « découper les US » ou d’« affiner les US », elle parle bien des user stories du backlog. Le pluriel reste « les US ».
Quelle est la composition d'une user story ?
Une bonne user story comporte trois ingrédients : un énoncé orienté utilisateur (le « En tant que… je veux… »), des critères d’acceptation testables qui décrivent le comportement attendu, et une notion de valeur (le « afin de… »). C’est la conversation autour de ces éléments (et non le ticket lui-même) qui fait la qualité de la story.
Quelle est la différence entre un epic et une user story ?
Un epic est une grande intention, trop volumineuse pour tenir dans un sprint : c’est exactement le candidat idéal au découpage. Une user story est le résultat de ce découpage : suffisamment petite pour être finie, verticale, testable. En clair, on découpe un epic en plusieurs user stories qui délivrent chacune de la valeur de façon incrémentale.
Allez plus loin sur le découpage et l’agilité concrète
Le découpage des user stories est une compétence qui se pratique en équipe. Nos formations agiles vous donnent les ateliers, les exemples et le coaching pour transformer vos sprints durablement.
