IDans ce chapitre, vous allez apprendre à enrichir votre story map pour qu’elle diffuse encore plus d’informations à l’équipe et aux parties prenantes concernées.
La story map est un artefact que l’équipe technique et les parties prenantes devraient consulter à plusieurs reprises tout au long du développement du produit.
Annotez votre story map avec les éléments suivants :
Photos des utilisateurs
User stories bloquées
Hypothèses et risques
UX ou wireframes
Certains produits ou systèmes impliquent plusieurs types d’utilisateurs ou rôles.
Par exemple, dans un système médical, on peut retrouver les rôles suivants : patients, médecins, infirmiers, administrateurs. Lorsqu’il y a plusieurs types d’utilisateurs, il peut être utile d’ajouter une photo sur la story map pour visualiser qui effectue quelle activité.
Les photos sur la story map permettent d’identifier chaque rôle. Elles sont placées au-dessus de l’activité correspondante. Vous pouvez également ajouter le nom du rôle utilisateur (ex. : patient, médecin, etc.) sous la photo pour clarifier encore davantage.

Il arrive que l’équipe technique ne puisse pas commencer ou terminer une user story à cause de facteurs externes (ex. : éléments à fournir, informations manquantes…).
Ce type de dépendance est fréquent. L’équipe peut être en attente de traductions, de visuels, de composants techniques ou tout simplement d’une réponse.
Quand une dépendance empêche d’avancer, la story peut être marquée comme bloquée. Cela signifie qu’un obstacle empêche la réalisation du travail.
Pour signaler ces cas, on peut utiliser des points rouges ou des post-its sur la story map.

Cela permet de :
Visualiser immédiatement les user stories bloquées
Compter facilement combien il y en a
Les prioriser selon leur urgence
💡 Exemple : un blocage sur une story prévue dans deux versions est moins prioritaire qu’un blocage sur une story de la version en cours. Toute l’équipe peut ainsi se concentrer sur ce qui est critique.

l est aussi important d’indiquer quelles stories contiennent des hypothèses ou des risques. Comme pour les blocages, on peut utiliser des pastilles de couleurs différentes.
Exemples :
Risque : une story pourrait produire du code peu performant en cas de fort trafic.
Hypothèse : les utilisateurs peuvent uniquement payer par carte bancaire, et pas avec PayPal ou d’autres solutions.
Ces éléments sont souvent identifiés lors des sessions de planification. Pour s’en souvenir, on peut écrire l’hypothèse ou le risque au dos de la carte ou du post-it correspondant.

Si l’équipe design a créé des wireframes (ou maquettes), vous pouvez aussi les intégrer à la story map.
Ces éléments visuels, souvent appelés UX (expérience utilisateur), permettent aux personnes extérieures à l’équipe de mieux comprendre à quoi ressemblera l’interface pour chaque activité.

Astuce : placez les wireframes à droite de la story map.
Ainsi, vous visualisez non seulement :
quelles user stories correspondent à quelles activités,
quelles stories sont incluses dans chaque version,
mais aussi à quoi ressemblera concrètement l’interface.
C’est bien plus parlant qu’une simple liste de stories dans un tableau Excel !
La story map n’est pas uniquement un outil de lancement produit. Elle peut aussi servir tout au long du cycle de vie d’un produit existant.
Vous pouvez :
La faire évoluer au fil du temps
Ajouter de nouvelles swimlanes et de nouveaux sprints
L’objectif principal n’est pas la carte en elle-même, mais la méthode pour structurer le backlog.
Un backlog plat peut contenir toutes les informations (versions, sprints, fonctionnalités…), mais une story map vous offre un outil visuel et interactif, idéal pour annoter et clarifier votre travail.
La story map diffuse des informations — comme un radiateur ! Elle permet aux membres de l’équipe et aux parties prenantes de voir d’un coup d’œil ce qu’il faut savoir.
Pour la rendre encore plus précieuse, ajoutez-y :
Des photos pour indiquer quel type d’utilisateur réalise chaque activité
Les user stories bloquées
Les stories contenant des hypothèses ou des risques
Des éléments visuels comme des maquettes ou wireframes
Je vous recommande vivement le livre de Jeff Patton sur la story mapping.
Créer une story map ne se fait pas seul. Découvrez comment en construire une en équipe dans le chapitre suivant !