Un backlog plat est une liste triée par priorité. Il vous dit quoi construire ensuite, mais pas comment les pièces s'assemblent, et il est facile de livrer dix fonctionnalités soignées qui ne forment rien que l'utilisateur peut terminer. Une carte d'histoires utilisateur corrige cela en disposant les histoires le long du parcours de l'utilisateur, afin que vous puissiez voir le produit entier et découper une première livraison qui fonctionne du début à la fin.
Ce guide explique comment construire une carte d’histoires, comment transformer sa première tranche en périmètre d’MVP, comment vérifier chaque histoire avec INVEST, et les schémas de découpage qui transforment les grandes histoires en histoires de taille de sprint. Si vous avez besoin des bases d’abord, commencez par comment rédiger des user stories.
Qu’est-ce qu’une carte d’histoires utilisateur
La cartographie d’histoires a été introduite par Jeff Patton, d’abord dans un article de 2005, « It's all in how you slice it », puis dans sa publication de 2008 The new user story backlog is a map, et plus tard dans son livre User Story Mapping (O'Reilly, 2014). Voir aussi ses ressources sur la cartographie d’histoires et la entrée du glossaire de l’Agile Alliance.
Une carte a deux directions :
- De gauche à droite, c’est le récit : les grandes activités par lesquelles l’utilisateur passe, dans l’ordre, et les étapes à l’intérieur de chacune. Cette rangée supérieure est appelée la colonne vertébrale.
- De haut en bas, c’est la priorité et le détail : sous chaque étape se trouvent les histoires qui la rendent possible, avec les plus essentielles en haut et les alternatives, cas limites et fonctionnalités souhaitables en dessous.
Les lignes horizontales traversant la carte la divisent ensuite en tranches de version. Tout ce qui est au-dessus de la première ligne constitue la première version ; elle devrait couvrir chaque activité de la colonne vertébrale, même de manière minimale.
Comment construire une carte d’histoires en 6 étapes
Vous pouvez le faire sur un mur avec des post-it ou sur un tableau blanc numérique. Invitez les personnes qui décideront du périmètre et celles qui le construiront : produit, design, au moins un développeur, et idéalement quelqu’un qui parle aux clients. Une première carte pour un petit produit prend généralement une session de travail de quelques heures.
1. Cadrer le problème
Notez à qui le produit s’adresse, le problème qu’il résout et le résultat qui vous indiquera que la première version a fonctionné. Limitez-vous à trois phrases en haut de la carte. Chaque coupe ultérieure est jugée par rapport à ce résultat.
2. Cartographier la colonne vertébrale
Demandez « que fait l’utilisateur en premier, et ensuite quoi ? » et écrivez chaque activité sur une carte, de gauche à droite. Utilisez des verbes : « Trouver un promeneur », pas « Rechercher ». Puis décomposez chaque activité en étapes. Racontez l’histoire à voix haute en avançant ; les lacunes deviennent évidentes quand quelqu’un dit « attendez, comment sont-ils arrivés ici ? »
3. Explorer les détails
Sous chaque étape, ajoutez les histoires qui la font fonctionner : options, alternatives, cas d’erreur, besoins administratifs. Ne filtrez pas encore. C’est ici que la carte se rentabilise, car les gens remarquent les pièces manquantes lorsqu’ils peuvent voir tout le parcours d’un coup.
4. Trouver le squelette marchant
Le squelette marchant (un terme d’Alistair Cockburn) est la version la plus fine du produit qui fonctionne de bout en bout. Choisissez l’histoire sous chaque étape dont l’utilisateur ne peut pas se passer, et déplacez-la en haut. Si une étape n’a rien d’essentiel, demandez si elle appartient à la colonne vertébrale.
5. Trancher les versions
Tracez des lignes horizontales pour regrouper les histoires en versions. Donnez à chaque tranche un nom qui énonce le résultat, comme « Les propriétaires peuvent réserver et payer une promenade », plutôt que « Version 1 ». Chaque tranche doit être utilisable seule et répondre à une question que vous vous posez sur le produit.
6. Planifier la première tranche et garder la carte vivante
Rédigez les critères d’acceptation pour les histoires de la première tranche (notre modèle d'histoire utilisateur a trois formats), vérifiez chacune avec INVEST, découpez celles qui sont trop grandes, et déplacez-les dans le backlog de sprint. Gardez la carte visible et mettez-la à jour après chaque version ; c’est un outil de planification, pas le résultat d’un atelier ponctuel.
Exemple : une carte d’histoires pour une application de promenade de chiens
Voici une carte condensée pour une place de marché qui connecte les propriétaires de chiens avec des promeneurs locaux. Les colonnes sont la colonne vertébrale ; chaque rangée est une tranche de version.
| Tranche | Inscription | Trouver un promeneur | Réserver une promenade | Payer | Pendant la promenade | Après la promenade |
|---|---|---|---|---|---|---|
| Squelette marchant (MVP) | Inscription par e-mail ; ajout d'un chien | Voir une liste de promeneurs approuvés près d'un code postal | Demander un créneau horaire ; le promeneur accepte par e-mail | Paiement par carte lors de la réservation | Le promeneur indique le début et la fin de la promenade | Le propriétaire reçoit un message de synthèse |
| Version 2 | Connexion avec Google ou Apple ; plusieurs chiens | Filtrage par prix et disponibilité ; profils de promeneurs avec photos | Acceptation et refus dans l'application ; rappels | Cartes enregistrées ; remboursement automatique en cas d'annulation | Localisation en direct sur une carte | Évaluations et avis |
| Plus tard | Codes de parrainage | Promeneurs favoris | Réservations hebdomadaires récurrentes | Abonnements et pourboires | Mises à jour photo pendant la promenade | Réserver en un clic |
Notez ce que le squelette omet : pas de suivi en direct, pas d'avis, pas de messagerie dans l'application, et l'approbation des promeneurs est manuelle. Mais un propriétaire peut toujours passer de l'inscription à une promenade terminée et payée, ce qui suffit à tester si les gens réserveront un inconnu pour promener leur chien.
Comment la carte devient une portée MVP
La tranche supérieure d'une bonne carte est votre portée MVP. Utilisez ces vérifications avant de vous y engager :
- Elle couvre chaque activité de l'ossature. Un produit qui permet de réserver mais pas de payer n'est pas un MVP ; c'est une demi-démonstration.
- Elle sert un utilisateur principal et un parcours principal. Les rôles secondaires (administrateurs, partenaires) reçoivent le minimum nécessaire pour maintenir le parcours en fonctionnement, souvent un tableur ou une étape manuelle.
- Elle teste une hypothèse spécifique. Écrivez la question que la tranche répond à côté, par exemple « Les propriétaires pailleront-ils avant de rencontrer le promeneur ? »
- Le travail manuel en coulisses est autorisé. Approuver les promeneurs manuellement ou envoyer les synthèses vous-même est acceptable pour les premiers utilisateurs, et vous indique ce qui mérite d'être automatisé.
- Elle s'adapte à votre budget et à votre calendrier. Si ce n'est pas le cas, coupez des histoires dans chaque colonne (divisez-les, en utilisant les modèles ci-dessous) plutôt que de supprimer des colonnes entières.
Pour les fondateurs sans cofondateur technique, la carte est aussi le document le plus utile que vous puissiez remettre à une équipe de développement : elle montre l'ensemble du produit, la première version et le raisonnement derrière la coupe, en une page. Notre guide sur construire un MVP en tant que fondateur non technique couvre les étapes suivantes.
La liste de contrôle INVEST
Une fois les histoires sur la carte, vérifiez chacune d'elles dans la première tranche selon INVEST, l'acronyme proposé par Bill Wake en 2003 dans INVEST dans de bonnes histoires, et tâches SMART.
| Lettre | Signification | Question à poser | En cas d'échec |
|---|---|---|---|
| I | Indépendant | Pouvons-nous construire et publier cela sans attendre une autre histoire ? | Combinez les histoires fortement couplées, ou divisez-les différemment pour que chacune apporte une valeur par elle-même |
| N | Négociable | La solution est-elle encore ouverte à la discussion ? | Retirer le détail d'implémentation de l'histoire ; le garder dans les notes |
| V | Valuable | Un utilisateur ou l'entreprise remarquerait-il si cela était livré ? | Fusionner les tâches techniques dans l'histoire qu'elles servent |
| E | Estimable | L'équipe en sait-elle assez pour l'estimer ? | Lancer une exploration à durée limitée, ou poser les questions qui bloquent l'estimation |
| S | Petit | Est-ce que cela tient confortablement dans un seul sprint ? | Le diviser selon l'un des modèles ci-dessous |
| T | Testable | Pouvons-nous rédiger des critères d'acceptation qui passent ou échouent ? | Remplacer les mots vagues (« rapide », « facile ») par des résultats observables |
L'indépendance est le critère le plus difficile à respecter pleinement, et il est acceptable de le considérer comme un objectif plutôt qu'une règle. Les critères « Petite » et « Testable » sont ceux sur lesquels il faut être strict.
Comment diviser les histoires utilisateur
Diviser les histoires verticalement : chaque partie doit toujours livrer quelque chose que l'utilisateur peut voir, à travers chaque couche du système. Diviser par couche (« construire la base de données », « construire l'API », « construire l'écran ») produit des morceaux qui ne livrent rien tant que les trois ne sont pas terminés, ce qui contredit l'objectif. Ces modèles, rassemblés dans le Guide Humanizing Work sur la division des histoires utilisateur par Richard Lawrence et Peter Green, couvrent la plupart des cas.
Étapes du flux de travail
Diviser un processus multi-étapes en ses étapes, ou construire d'abord la version simple de bout en bout et ajouter les étapes plus tard. « Réserver une promenade » devient : demander un créneau ; le promeneur accepte ; le propriétaire reçoit une confirmation. Plus tard : le promeneur propose un autre horaire.
Variations des règles métier
Si une histoire a plusieurs règles, livrer d'abord la plus courante. « Remboursements en cas d'annulation » devient : remboursement complet si annulé 24 heures à l'avance ; remboursement partiel dans les 24 heures ; aucun remboursement après le début de la promenade.
Variations de données
Commencer par un type de données et ajouter les autres. « Rechercher par localisation » devient : rechercher par code postal ; puis par localisation actuelle ; puis en dessinant une zone sur une carte.
D'abord le chemin heureux, ensuite les chemins malheureux
Construire d'abord le chemin de succès principal, puis gérer les échecs comme des histoires séparées, classées par fréquence et par gravité des dommages. « Payer par carte » devient : paiement réussi ; carte refusée ; fournisseur de paiement indisponible.
Opérations
« Gérer les chiens » cache créer, afficher, modifier et supprimer. Souvent, seuls créer et afficher sont nécessaires pour la première version.
Variations d'interface ou de plateforme
Livrer d'abord sur une seule plateforme ou avec une seule méthode d'entrée. Web avant mobile, ou anglais avant d'autres langues, si vos premiers utilisateurs le permettent.
Version simple d'abord, différer la performance
Faire fonctionner, puis optimiser la vitesse. Une liste de promeneurs qui se charge en trois secondes pour 50 promeneurs est acceptable pour une ville pilote ; optimiser lorsque les chiffres le justifient, en tant qu'histoire distincte.
Exploration
Lorsqu'une histoire ne peut pas être estimée à cause d'une inconnue (« pouvons-nous obtenir la localisation en arrière-plan sur les deux plateformes téléphoniques ? »), séparer une courte investigation à durée limitée. Le résultat de l'exploration est une connaissance et une histoire mieux dimensionnée, pas une fonctionnalité livrée.
SPIDR : une version courte à retenir
Mike Cohn regroupe les principales techniques de division sous l'acronyme SPIDR : Explorations, Chemins, Interfaces, Données et Règles (Cinq façons simples mais puissantes de diviser les histoires utilisateur). Si une histoire est trop grande et que vous ne savez pas par où commencer, parcourez les cinq dans cet ordre.
| Technique | Diviser par | Exemple |
|---|---|---|
| Explorations | Rechercher l'inconnu d'abord | Exploration de deux jours sur la localisation en arrière-plan avant d'estimer le suivi en direct |
| Cheminements | Cheminements alternatifs dans le récit | Paiement par carte maintenant ; paiement par portefeuille plus tard |
| Interfaces | Type d'appareil, de navigateur ou d'interface | Réservation par le propriétaire sur le web en premier, application mobile en second |
| Données | Types ou plages de données | Un chien par réservation au départ ; plusieurs chiens plus tard |
| Règles | Règles métier, assouplies au départ | Aucune règle d'annulation dans le pilote ; politique de remboursement en tant que récit distinct |
Erreurs courantes en cartographie de récits
- Cartographier des fonctionnalités au lieu des activités utilisateur. Une colonne vertébrale de « Connexion, Tableau de bord, Paramètres » décrit des écrans, pas un parcours.
- Construire la première tranche en profondeur d'une seule colonne. Peaufiner l'inscription avant que la réservation n'existe ne laisse rien à tester.
- Laisser la carte devenir trop détaillée. Si vous rédigez des critères d'acceptation sur le mur, vous êtes passés de la cartographie à l'affinage.
- Cartographier sans les développeurs dans la pièce. Les tranches dessinées sans eux cachent souvent des récits coûteux en haut.
- Considérer la carte comme terminée. Après chaque version, intégrez ce que vous avez appris sur la carte et recoupez la tranche suivante.
Pour des récits bien formés que vous pouvez adapter à votre propre carte, voir nos exemples d'histoires utilisateur.
Outils pour la cartographie de récits
Un mur et des post-it fonctionnent toujours le mieux pour la première session avec tout le monde dans une seule salle. Pour les équipes à distance, les tableaux blancs généraux tels que Miro et FigJam disposent de modèles de carte de récits, et des outils dédiés tels que StoriesOnBoard synchronisent les cartes avec les suiveurs de backlog. Jira et des suiveurs similaires peuvent afficher des récits groupés par épique, ce qui vous donne la colonne vertébrale, mais vous avez généralement besoin d'un plugin ou d'un tableau blanc pour voir les tranches de version. Choisissez l'outil que votre équipe gardera ouvert ; une carte que personne ne met à jour cesse d'être utile en un ou deux sprints.
Questions fréquemment posées
Qu'est-ce que la cartographie de récits utilisateur ?
Une technique, introduite par Jeff Patton, pour disposer les récits utilisateur le long du parcours effectué par l'utilisateur (la colonne vertébrale, de gauche à droite) et par priorité (de haut en bas). Les lignes horizontales divisent la carte en tranches de version, afin que l'équipe puisse planifier des versions qui fonctionnent de bout en bout.
Quelle est la différence entre une carte de récits et un backlog produit ?
Un backlog est une liste unique ordonnée par priorité. Une carte de récits montre les mêmes récits en deux dimensions, par activité utilisateur et par priorité, afin que vous puissiez voir comment ils s'assemblent et si une version couvre tout le parcours.
Qu'est-ce qu'un squelette de marche ?
La version la plus fine d'un produit qui fonctionne du début à la fin, avec un récit essentiel sous chaque étape du parcours. Le terme vient d'Alistair Cockburn ; sur une carte de récits, c'est généralement la première tranche de version.
Que signifie INVEST ?
Indépendant, Négociable, Valuable, Estimable, Petit et Testable. Bill Wake l'a proposé en 2003 comme une liste de contrôle pour de bons récits utilisateur.
À quel point un récit utilisateur doit-il être petit ?
Assez petit pour que l'équipe puisse le terminer, le tester et le démontrer dans un seul sprint, et idéalement en quelques jours. Si un récit prend régulièrement un sprint entier, divisez-le.
Qu'est-ce que SPIDR ?
Un ensemble de cinq techniques de découpage de récits décrites par Mike Cohn : Spikes, Cheminements, Interfaces, Données et Règles.
Qui devrait participer à une session de cartographie de récits ?
Les personnes qui décident de la portée et celles qui vont le construire : propriétaire du produit ou fondateur, designer, au moins un développeur, et idéalement quelqu'un qui parle aux clients, comme le support ou les ventes.
Vous avez une carte, ou juste une idée, et avez besoin que la première tranche soit construite ? Nous pouvons vous aider à découper une portée MVP qui fonctionne de bout en bout et à la livrer en sprints courts. Voir nos plans de développement mensuels.