Story Mapping
Le story mapping dispose les stories d'une solution sur une grille à deux dimensions. La ligne du haut porte, de gauche à droite, les thèmes ou activités du parcours client, dans l'ordre où il les traverse; sous chaque thème s'empilent les stories qui le réalisent, rangées par priorité décroissante. L'Agile Extension au guide BABOK donne à la technique trois objets: comprendre la fonctionnalité d'un produit, comprendre le flux d'usage et prioriser la livraison. La carte est faite pour rester affichée: l'équipe y lit ce que la solution fait de bout en bout, ce qui part dans la prochaine release et ce qui attend.
Objectif
La technique produit une carte, une grille dont la dimension horizontale porte la séquence et le regroupement des grandes étapes du produit, la dimension verticale le détail et la priorité des stories. Elle appuie une décision: le découpage des mises en service, que la ligne de release trace en travers de la carte. L'Agile Extension au guide BABOK y voit un moyen de comprendre le besoin tout en concentrant l'analyse sur les éléments les plus prioritaires.
L'équipe de livraison a la carte devant elle pendant les séances de planification de release. Sa lecture rend visibles les dépendances qu'engendre le flux d'usage prévu: une story qui en suppose une autre livrée avant elle se repère à leur position sur la ligne du haut. La carte sert aussi à l'appréciation du risque, puisqu'elle montre comment les stories devront fonctionner ensemble pour livrer de la valeur d'affaires.
Les cartes posées sur la grille sont des stories déjà identifiées: la technique les ordonne et fait apparaître celles qui manquent; elle ne découpe pas une story trop grosse. Vous trouverez le format d'une story et ses critères de qualité du côté des user stories. Le §7.20.2 de l'Agile Extension qualifie le story mapping de technique de décomposition, au sens où la lecture descend de la vue de bout en bout aux stories détaillées; le découpage d'une story trop grosse pour être estimée ou livrée relève de la décomposition de stories, traitée au §7.18. Le §7.20.3.4 met les deux activités dans l'ordre: la séance de cartographie priorise les stories du moment et désigne celles qui partiront en élaboration ou en décomposition.
Le tableau 7.0.1 de l'Agile Extension range la technique parmi celles de la gestion des exigences, du côté des équipes internes.
Usage
Quand l'utiliser
- Planification de release: décider ce qui part dans la prochaine mise en service et dans quel ordre.
- Vue d'ensemble perdue: le rang d'une story dans un backlog plat ne dit plus à quel moment du parcours client elle sert; la carte rétablit la vue de bout en bout pendant la livraison.
- Trous fonctionnels soupçonnés: parcourir la ligne du haut fait apparaître les stories manquantes.
- Plusieurs publics à arbitrer: la carte montre à quels personas profite chaque tranche.
- Enchaînement à vérifier: le flux prévu montre quelles stories doivent en précéder d'autres.
- Cheminement d'une donnée à comprendre: la carte suit une donnée à travers le système.
Quand ne pas l'utiliser
- Une story unique trop grosse: la grille ordonne des stories existantes, prendre la décomposition de stories.
- Contexte sans parcours d'usage: rien à ranger sur l'axe horizontal, ordonner le backlog par une technique de priorisation.
Description
Les deux axes
Une carte se lit dans deux sens qui répondent à deux questions: de gauche à droite, ce que la solution fait de bout en bout; de haut en bas, dans quel ordre les morceaux arrivent. Les thèmes de la ligne du haut sont posés dans l'ordre linéaire où un client les traverse et couvrent l'ensemble des personas connus. Sous un thème, la story la plus prioritaire occupe le haut de la pile, les suivantes descendent.
Les trois éléments de structure
| Élément | Ce qu'il porte | Ce qu'il permet de décider |
|---|---|---|
| Thèmes ou activités | La ligne du haut: tous les thèmes ou activités connus, en parcours linéaire. Le guide cite l'usage d'un bancomat, de l'activation de la machine au choix entre une autre transaction et la sortie. | Le périmètre d'usage et l'endroit du parcours où chaque story se situe. |
| Stories ou fonctionnalités | Sous chaque thème, toutes les fonctionnalités connues qui s'y rattachent. Une story sert un persona ou plusieurs. | Ce qui reste à construire pour qu'un thème soit tenu. |
| Ordre de priorité | L'empilement de haut en bas sous chaque thème. Le rang place en tête les stories qui servent les personas les plus nombreux et les mieux classés, ainsi que celles dont la livraison conditionne les fonctionnalités suivantes. | La séparation des fonctionnalités entre les releases. |
Construire la carte
- Préparer les thèmes et les stories avant la séance
Le guide la demande pour que le groupe passe son temps à prioriser et à comprendre le parcours client, plutôt qu'à découvrir le matériel. - Poser la ligne du haut
Un thème sans story signale un trou dans le backlog ou un thème hors du parcours. - Accrocher les stories sous leur thème
Chaque story rejoint le thème qu'elle réalise. Une story qui trouve deux thèmes est le plus souvent deux stories. - Empiler par priorité
L'ordre se discute colonne par colonne, puis se compare d'une colonne à l'autre. - Tracer la ligne de release
Elle sépare ce qui part de ce qui attend. Patton la place en travers de toute la carte, pour que la première mise en service donne un parcours praticable de bout en bout. - Relire la carte de bout en bout
Ce qui reste trop gros part en décomposition, ce dont la livraison approche part en élaboration.
Animer la séance
La technique se passe de facilitateur dédié. Elle se pratique le plus souvent en groupe, autour du mur ou du tableau. Le responsable de produit tranche quand un arbitrage bloque. Cette économie tient à la préparation: si les thèmes et les stories arrivent en séance sur des cartes déjà écrites, la discussion porte sur leur place, qui se règle en déplaçant une carte.
Ce qui fait échouer une carte
La ligne du haut écrite en écrans
Quand les thèmes reprennent les modules de l'application, la ligne horizontale cesse de porter un parcours et la carte redevient un backlog en colonnes. Le test: lire la ligne du haut à voix haute; elle doit dire ce qu'un client fait, dans l'ordre où il le fait. « Écran de saisie, écran de validation, module de reporting » ne passe pas ce test.
La ligne de release qui descend le long d'une colonne
Livrer un thème entier avant d'attaquer les autres donne une solution qu'aucun client ne peut traverser. Une release qui n'occupe qu'une colonne se reconnaît à l'œil sur la carte.
La carte prise pour une analyse de dépendances
Le guide énonce la limite: une carte montre un flux, sans analyser ni dessiner les dépendances entre exigences. Elle facilite cette analyse en montrant l'enchaînement prévu; l'analyse reste un travail distinct, conduit sur les exigences.
La carte trop grande pour un mur
Sur une solution étendue, une carte unique devient ingérable et le guide prévoit plusieurs cartes couvrant un programme de travail. Le découpage se fait par produit ou par domaine d'usage, avec un point de raccord explicite là où un parcours passe d'une carte à l'autre.
Considérations IA
Un modèle de langage abrège la préparation. À partir d'un processus documenté ou de notes d'entretien, il propose une première ligne de thèmes dans l'ordre du parcours, que l'équipe corrige avant la séance. À partir d'un backlog plat, il regroupe les stories sous des thèmes candidats et signale celles qu'aucun thème n'accueille, souvent le premier indice d'un trou dans le parcours. Il rédige les stories manquantes que la relecture fait apparaître.
L'ordre vertical échappe au modèle. Il se décide sur des revenus, des échéances contractuelles et des obligations réglementaires que le modèle ne connaît pas, et la ligne de release engage l'équipe devant des parties prenantes. Une carte produite d'un bloc et affichée telle quelle prive la séance de son objet: le guide décrit une activité de groupe où la discussion sur le parcours du client vaut autant que la grille obtenue.
Ce qui part dans le modèle est un export de backlog, où les stories d'une application bancaire citent en exemple des données de clients réels. Il ne va pas dans un service cloud public tant que l'usage n'est pas couvert au sens de la loi fédérale sur la protection des données (LPD).
Exemples
Une banque de détail suisse cartographie le paiement de factures QR dans son application d'e-banking. La ligne du haut suit le parcours du client: se connecter, scanner la facture QR, vérifier le montant et l'échéance, confirmer le paiement, retrouver la confirmation.
La ligne de release traverse les cinq colonnes. La première mise en service prend la story du haut de chaque thème, ce qui donne un client capable de payer une facture QR de bout en bout: ouverture de session, lecture du code par la caméra, contrôle du montant scanné contre la facture papier, confirmation par le deuxième facteur, quittance en PDF. Sept cartes restent sous la ligne et améliorent ce parcours sans le conditionner. Quatre se répartissent une par colonne: la session maintenue sur un appareil de confiance, la saisie manuelle du numéro de référence quand la caméra échoue, le paiement daté à l'échéance, la recherche dans l'historique. Les trois autres tombent sous « vérifier le montant et l'échéance », qui compte donc quatre cartes et devient la colonne la plus haute: un montant laissé ouvert que le client complète, une facture déjà payée le mois précédent, un refus au-delà du plafond journalier de CHF 5'000.
Visualisations
Le dessin porte trois informations qu'une liste ordonnée ne porte pas. La flèche du haut donne l'ordre du parcours, si bien qu'un thème mal placé se voit. La ligne de release montre si la mise en service forme une tranche traversant toute la carte. La hauteur inégale des piles indique où se concentrent les cas particuliers.
Cette dernière lecture sert à l'estimation. Une pile haute est un thème discuté jusqu'à ses exceptions; une pile basse dit soit qu'il est simple, soit que personne ne l'a encore ouvert. Le second cas se paie dans l'itération, quand les exceptions non écrites arrivent.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Thèmes et stories sont écrits avant la séance; le mur ou le tableau partagé se réserve d'avance et le groupe doit être réuni. |
| Exécution | Moyen | Une séance de deux à trois heures pose la carte d'un produit, sans facilitateur dédié mais avec le groupe de livraison au complet. |
| Documentation | Moyen | La carte se reporte dans l'outil de backlog et se tient à jour à chaque changement de priorité: carte et backlog divergent dès la première repriorisation qui n'est pas reportée. |
Outils
Le mur et les notes autocollantes sont la forme d'origine et restent la meilleure pour la première passe: la carte se manipule à plusieurs mains, elle reste affichée devant l'équipe et personne n'attend son tour au clavier. Elle demande une équipe réunie au même endroit et un mur assez large.
Le tableau blanc en ligne (Miro, Mural) porte la même manipulation pour une équipe distribuée, et la carte survit à la séance sous une forme que chacun retrouve. La lecture d'ensemble y est plus pauvre qu'au mur, puisqu'un écran montre rarement cinq colonnes garnies sans zoom.
Les outils de story mapping branchés sur le backlog (Easy Agile pour Jira, StoriesOnBoard, Avion) tiennent la carte et le backlog sur le même jeu de données. Ce qui se déplace sur la carte se déplace dans le backlog, ce qui supprime la ressaisie après la séance et la dérive entre les deux vues.
L'outil de backlog seul rend le service minimal. Une liste ordonnée n'a pas d'axe horizontal; un champ « thème » sur chaque story, plus un tri, reconstituent une lecture par colonne. Ce qui se perd est le regard d'ensemble sur le parcours.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.20 Story Mapping: l'objet de la technique, la grille à deux dimensions, les éléments (thèmes ou activités, stories ou fonctionnalités, ordre de priorité) et la facilitation, l'affichage de la carte pendant la planification de release, la lecture des dépendances et l'appréciation du risque, ainsi que les limites énoncées, dont l'absence d'analyse des dépendances entre exigences, la taille au-delà de laquelle plusieurs cartes deviennent nécessaires et les contextes qui ne sont pas orientés processus.
- IIBA, Agile Extension to the BABOK Guide, §7.0, tableau 7.0.1 Selecting the Right Technique: la technique rangée parmi celles de la gestion des exigences, du côté des équipes internes.
- Jeff Patton, It's All in How You Slice It, Better Software, janvier 2005, p. 16: l'article d'origine, qui propose le découpage d'une livraison en tranches traversant tout le parcours.
- Jeff Patton, The New User Story Backlog is a Map, 2008: l'article où Patton nomme la pratique et décrit la ligne du haut comme la colonne vertébrale du produit, lue de gauche à droite.
- Jeff Patton avec Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly Media, 2014, ISBN 978-1-4919-0490-9: le traitement complet, dont la tranche minimale qui traverse tout le parcours, que Patton reprend d'Alistair Cockburn sous le nom de walking skeleton.