Décomposition de stories
La décomposition de stories est la structure qui décrit les exigences d'une solution à des niveaux de détail décroissants: les objectifs de solution en haut, puis les fonctionnalités minimales commercialisables (minimal marketable features, MMF) ou composants, puis les stories, puis les critères d'acceptation qui valident chacune d'elles. L'Agile Extension au guide BABOK y soumet toute story trop grosse ou trop mal comprise pour être élaborée, estimée ou livrée. La descente est progressive: l'analyse initiale pose les objectifs, les MMF et les grandes stories; le bas de l'arbre se remplit à mesure que l'initiative avance. Le guide fixe aussi la base du découpage: la fonctionnalité valorisée par le client.
Objectif
L'Agile Extension au guide BABOK donne à la technique cet objet: exprimer les exigences d'une solution au niveau de détail qui convient, alignées sur les résultats recherchés. Son produit est une hiérarchie à quatre niveaux, du contexte d'ensemble aux critères d'acceptation d'une story, chaque niveau restant rattaché à celui du dessus.
L'affinement du backlog est l'activité récurrente, tenue en séance, où le découpage se pratique, alors que la décomposition de stories est la structure que ce découpage suit. La décomposition fonctionnelle traite n'importe quel sujet, une fonction, un processus ou le travail à faire, sous deux contrats vérifiés à chaque niveau: les enfants couvrent le parent, chaque enfant n'a qu'un parent. Sa profondeur se déduit de la tâche qui consommera l'arbre; celle de la décomposition de stories se déduit de la distance à la livraison, sous un test de valeur appliqué story par story. Les deux arbres sont donc de profondeur inégale. L'élaboration de story, traitée au §7.19 de l'Agile Extension, ajoute le détail et les critères à une story qui existe déjà: la décomposition change le nombre de stories, l'élaboration change ce qu'une story dit.
Le tableau 7.0.1 de l'Agile Extension la range dans la gestion des exigences et du côté des équipes internes, sans entrée pour les parties prenantes extérieures. La hiérarchie sert d'abord à ceux qui construisent, puisqu'elle ordonne un travail avant qu'il soit montrable.
Usage
Quand l'utiliser
- Story trop grosse pour être estimée ou livrée: le guide en fait le déclencheur.
- Démarrage d'initiative: poser les objectifs de solution et les MMF avant toute story détaillée.
- Planification de release: décider quelles fonctionnalités partent, dans quel ordre et jusqu'où.
- Équipe absorbée par le détail: la hiérarchie rattache chaque story à l'objectif d'affaires qui la justifie.
- Coordination avec la formation et la conduite du changement: les MMF donnent la maille sur laquelle ces travaux se calent.
- Backlog hérité d'un découpage technique: reconstruire les tranches autour de fonctionnalités que le client sait juger.
Quand ne pas l'utiliser
- Story déjà estimable et livrable: elle est mûre pour l'élaboration.
- Périmètre, processus ou organisation à découper: ces objets relèvent de la décomposition fonctionnelle.
- Story impossible à estimer dont la taille n'est pas en cause: l'obstacle est une inconnue, et un spike la lève.
Description
Les quatre niveaux
| Niveau | Ce qu'il porte | Ce qu'il permet de décider |
|---|---|---|
| Objectifs de solution | Le niveau le plus élevé des exigences d'affaires: les moteurs qui font entreprendre l'initiative. | Le référentiel contre lequel tout besoin détaillé est apprécié. |
| MMF / composant | Des regroupements logiques de fonctionnalités et de capacités que la solution doit offrir pour valoir une mise en service. Ils forment souvent les thèmes d'une release. | Ce qui part dans quelle release et le contexte d'ensemble du produit. |
| Story | Une user story, une job story, un cas d'utilisation ou une exigence à implémenter. | Ce qu'une équipe prend dans une itération. |
| Critères d'acceptation | Les conditions de satisfaction qui valident une story, écrites en listes, en spécifications ou en tests d'acceptation. | À quelles conditions la story est acceptée. |
Le deuxième niveau porte deux noms dans le guide lui-même: le §7.18 l'appelle MMF ou composant, quand le §6.7.1 écrit decompose epics to stories sur l'horizon de livraison. Un lecteur venu de SAFe ou d'un outil de backlog reconnaîtra l'objet sous le nom d'epic. Le quatrième niveau s'écrit lors de l'élaboration de story, sur la seule story dont la livraison approche; la décomposition, elle, s'arrête quand la story existe comme candidate.
Décomposer en largeur avant d'aller en profondeur
L'approche que l'Agile Extension nomme breadth-before-depth ordonne la descente: les objectifs d'affaires d'abord, puis les composants qui portent chacun un incrément de valeur pour le client, puis les stories, puis leurs critères d'acceptation. Une fois les MMF ou les groupes de fonctionnalités établis, des cas d'utilisation peuvent tenir la place des stories.
Sur une initiative agile, les premières activités d'analyse identifient les objectifs, les MMF et la plupart des grandes stories; le découpage de ces stories s'achève par incréments. Le guide en donne la raison: ces stories vont changer et la compréhension des exigences va évoluer, si bien que descendre tôt jusqu'au dernier niveau produit du travail à jeter.
La base du découpage
L'Agile Extension écarte trois bases de découpage: le processus (étape 1, étape 2, étape 3 d'un flux), l'architecture (construire la base de données, puis le serveur, puis l'interface) et la procédure (concevoir, construire, tester). La base retenue est la fonctionnalité valorisée par le client.
Deux catalogues de praticiens donnent les motifs de découpage qui tiennent cette contrainte. Richard Lawrence et Peter Green en recensent neuf: étapes du flux, variantes de règle de gestion, variantes de données, modes de saisie ou d'interface, cas simple contre cas complexe, report de la performance, effort principal, opérations CRUD (créer, lire, mettre à jour, supprimer), spike. Mike Cohn en retient cinq sous l'acronyme SPIDR: spike, chemin, interface, données, règles. Le spike figure dans les deux catalogues: en extraire un rend plus petite la story qui reste. C'est le découpage à employer quand l'inconnue interdit toute tranche de valeur. Le test de sortie, lui, vient des critères INVEST de Bill Wake. Deux d'entre eux tranchent ici: valuable, la story apporte quelque chose que le client sait juger; independent, elle se livre sans attendre les autres.
Ce qui fait échouer une décomposition
Le retour à la spécification détaillée en amont
Le guide nomme cet anti-pattern: traiter la décomposition de stories comme un moyen de revenir à la spécification détaillée établie en amont. L'arbre descend alors partout jusqu'aux critères d'acceptation. Le résultat est une spécification complète sous un autre nom. Le remède tient dans le just-enough, just-in-time: savoir quand cesser de décomposer, branche par branche, selon la distance qui sépare chaque MMF de sa livraison.
La tranche technique déguisée en story
« Créer la table des abonnements » porte la forme d'une story et la substance d'une tâche. Aucun client ne sait l'accepter, aucune démonstration ne la montre et une release faite de ces tranches n'expose rien d'utilisable tant que la dernière n'est pas terminée. En revue, si personne hors de l'équipe ne peut dire si la chose fonctionne, le découpage a suivi l'architecture.
La hiérarchie qui perd son sommet
Deux des forces que le guide lui reconnaît: garder les objectifs du projet présents à l'esprit et tracer toute fonctionnalité, demandée ou construite, jusqu'aux objectifs d'affaires. Ces deux forces se perdent quand les stories sont créées à plat dans l'outil, sans parent. Le backlog reste alimenté; on ne peut plus instruire à quoi une story sert et l'arbitrage se fait à la voix la plus forte.
Considérations IA
Un modèle de langage abrège le travail mécanique du découpage. Soumettre une grosse story avec le catalogue de motifs, en demandant pour chaque découpage proposé le motif appliqué, produit une liste de candidats que l'équipe trie. Le même modèle confronte une story déjà écrite aux critères INVEST et signale celles qui n'énoncent aucun bénéfice, symptôme d'un découpage technique. Il aide aussi à regrouper une liste de fonctionnalités en MMF candidats, que le responsable de produit accepte ou refond.
Le découpage que le modèle propose spontanément reprend les axes de découpage les plus fréquents dans ses données d'entraînement, qui sont techniques: une couche de données, une interface, un traitement par lots. C'est la base même que le §7.18 écarte. Le modèle doit donc recevoir la contrainte de valeur dans la consigne, et la sortie se relit sur ce point plutôt que sur sa forme, qui sera rarement en cause. L'ordre des MMF reste une décision du responsable de produit: elle se prend sur des revenus, des échéances contractuelles et des obligations réglementaires qu'un modèle ne connaît pas.
Un backlog contient des noms de clients, des extraits d'incidents et des détails de contrat. Ce matériel ne part pas vers un service externe sans que l'usage soit couvert; la loi fédérale sur la protection des données (LPD) s'applique à un extrait de backlog comme au reste.
Exemples
Un opérateur télécom suisse décompose l'application d'espace client qu'il veut ouvrir à ses abonnés mobiles. Voici l'état de l'arbre au moment où l'équipe planifie sa prochaine itération.
| Niveau | Contenu |
|---|---|
| Objectifs de solution | Le client gère son abonnement mobile sans appeler le service clientèle. |
| MMF / composant | Changement d'abonnement · Options d'itinérance (pas encore décomposé) |
| Stories sous « Changement d'abonnement » | En tant que client, je veux voir mon abonnement actuel et ma consommation de données du mois, afin de juger si je dois changer d'abonnement. En tant que client, je veux passer à un abonnement moins cher dès le prochain cycle de facturation, afin de cesser de payer des données que je n'utilise pas. En tant que client, je veux passer à un abonnement plus cher le jour même, afin de disposer tout de suite des données qui me manquent. En tant que client dont l'appareil est subventionné, je veux voir le palier d'abonnement que mon contrat impose jusqu'à son échéance, afin de savoir jusqu'où je peux descendre. |
| Critères d'acceptation de la story « passer à un abonnement moins cher » | Le nouvel abonnement s'applique le premier jour du cycle de facturation suivant. Le client voit le nouveau prix mensuel, CHF 29 contre CHF 39 pour l'abonnement en cours, dans une confirmation qu'il valide. Un changement déjà programmé pour le cycle en bloque un second jusqu'à sa prise d'effet. |
Ces quatre stories viennent d'une seule, apportée trop grosse en affinement: « En tant que client, je veux changer d'abonnement depuis l'espace client, afin de payer ce que je consomme. » Deux motifs la découpent. Les étapes du flux détachent la consultation: voir son abonnement et sa consommation du mois est une action qui se suffit à elle-même et qui sert déjà au client à décider. Les variantes de règle de gestion séparent ensuite trois cas: une baisse prend effet au cycle de facturation suivant, une hausse le jour même et un abonnement souscrit avec un appareil subventionné ne descend pas sous son palier avant l'échéance du contrat. La baisse part dans l'itération; la consultation, la hausse et le cas de l'appareil subventionné restent des stories candidates sous le même MMF. Chacune passe le test de sortie INVEST: elle se livre sans attendre les autres et elle change quelque chose que le client sait juger.
« Options d'itinérance » reste au niveau du MMF tant que sa livraison n'est pas proche, et les critères d'acceptation ne sont écrits que pour la story que l'équipe prend dans l'itération. Le client qui baisse sa formule économise CHF 10 par mois, soit CHF 120 sur douze mois; pour l'opérateur, la même somme est un revenu d'abonnement en moins. Ce qui justifie la story est l'objectif posé en haut de l'arbre: un changement d'abonnement obtenu sans appeler le service clientèle.
Visualisations
La technique se dessine en quatre rangées superposées, reliées de haut en bas. La rangée du haut, celle des objectifs de solution, porte une boîte unique. La deuxième porte les MMF, la troisième les stories, la quatrième les critères d'acceptation de la seule story dont la livraison est proche. Le nombre de branches est inégal d'un nœud à l'autre, puisque le découpage suit la valeur.
Le dessin fait voir la profondeur inégale des branches: une branche proche de la livraison descend jusqu'aux critères d'acceptation, sa voisine s'arrête au MMF. Un arbre dont toutes les branches touchent le quatrième niveau au même moment montre le retour à la spécification détaillée en amont.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Faible | Les objectifs de solution viennent de la vision et du dossier d'investissement; la technique les reprend et ouvre l'arbre. |
| Exécution | Moyen | Une passe initiale en atelier pour les objectifs et les MMF, puis un découpage qui revient à chaque affinement du backlog pendant toute l'initiative. |
| Documentation | Faible | La hiérarchie vit dans l'outil de backlog, sous forme de liens parent-enfant; aucun document séparé à tenir. |
Outils
L'outil de gestion de backlog porte la hiérarchie: Jira relie epic et story, Azure DevOps ajoute un niveau feature entre les deux, GitLab empile epics et issues. Aucun ne propose exactement les quatre niveaux du guide, si bien que la correspondance se décide une fois et s'inscrit dans les conventions de l'équipe. À défaut, deux équipes classent le même objet à deux étages et les vues consolidées deviennent fausses.
Le mur ou le tableau partagé (Miro, Mural ou des notes autocollantes sur une paroi) convient à la première passe en largeur, celle qui se fait à toute l'équipe. Déplacer une carte d'un niveau à l'autre s'y fait en un glisser-déposer, propriété recherchée tant que le regroupement en MMF n'est pas stabilisé; le contenu descend ensuite dans l'outil.
Le catalogue de motifs de découpage, imprimé sur une carte posée sur la table d'affinement, transforme « cette story est trop grosse » en un découpage nommé. Les neuf motifs de Lawrence et Green comme les cinq de SPIDR tiennent sur une page, et l'équipe qui les a sous les yeux propose des découpages par valeur.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.18 Story Decomposition: l'objet de la technique, le déclencheur d'une story trop grosse ou trop mal comprise, l'approche breadth-before-depth et son caractère progressif, les quatre éléments que sont les objectifs de solution, le MMF ou composant, la story et les critères d'acceptation, ainsi que les forces et les limites énoncées, dont la traçabilité vers les objectifs d'affaires, l'appui à la planification de release, l'anti-pattern du retour à la spécification détaillée en amont et l'exclusion du découpage par processus, architecture ou procédure.
- IIBA, Agile Extension to the BABOK Guide, §7.0, tableau 7.0.1 Selecting the Right Technique: la technique rangée parmi les techniques de gestion des exigences, du côté des équipes internes.
- Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003: l'origine des six critères INVEST, dont valuable et independent servent de test de sortie à un découpage.
- Richard Lawrence et Peter Green, The Humanizing Work Guide to Splitting User Stories, Humanizing Work: catalogue de praticiens, non normatif; les neuf motifs de découpage d'une story.
- Mike Cohn, SPIDR: Five Simple but Powerful Ways to Split User Stories, Mountain Goat Software: catalogue de praticiens, non normatif; les cinq motifs de l'acronyme SPIDR.