Story Mapping 101

De Wiki Agile du @GroupeCESI
Révision datée du 29 septembre 2019 à 16:16 par Fabrice Aimetti (discussion | contributions) (Backlogs vs Story Maps)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à : navigation, rechercher

Auteur : David Hawks
Source : Story Mapping 101
Date : 09/08/2017


Traducteur : Fabrice Aimetti
Date : 14/11/2018


Traduction :

Les backlogs peuvent être déroutants. Ils commencent typiquement par une liste de features de haut niveau, que nous pouvons appeler "epics" qui donnent du sens à toutes les personnes impliquées. Cependant, alors que nous commençons à décomposer au fur et à mesure en stories sprintables, chacun en vient très vite à se perdre et la seule personne possédant "l'anneau de décodage" est le Product Owner. Il est le seul à savoir comment toutes les stories secondaires se lient les unes aux autres.

Epics-stories-backlog fr.png

Backlogs vs Story Maps

Les défis imposés par les traditionnels backlogs sont liés au fait qu'ils ne communiquent pas la notion de workflow. Cela rend difficile de repérer les éventuels vides existants. De plus, nous perdons le contexte métier lorsque nous essayons de prioriser les plus petites stories entre elles.

Les Story Maps furent inventées par Jeff Patton (son livre) pour aider à découvrir les exigences en partant du point de vue de l'expérience utilisateur. Le processus de création d'une Story Map est un exercice collaboratif mené avec les parties prenantes. Cela nous aide à transformer notre approche de livraison des exigences vers une approche de découverte des exigences.

Comment créer la Story Map initiale

J'aime utiliser deux approches lorsqu'on construit la carte :

Raconter une histoire : Demander à l'un des experts du domaine de raconter une histoire avec les activités et les tâches qu'il exécute. Pendant qu'il raconte l'histoire, de nombreuses personnes (équipe de dév. ?) est armée de post-its et de marqueurs. En entendant une tâche dont l'utilisateur a besoin, une des personnes l'écrit sur un post-it et le place sur le mur. Nous les plaçons grossièrement dans l'ordre temporel de gauche à droite, même si rien n'est parfaitement linéaire et c'est ok. Ci-dessous, un exemple de story map pour un site de e-commerce.
Tell-a-story fr.png

Tout le monde écrit : c'est quelque chose qui fonctionne généralement lorsque nous disposons de plusieurs experts du domaine. Chacun écrit les tâches qu'il souhaiterait réaliser, puis les combine en 1 carte en supprimant les doublons.

Créer la Story Map

Une fois que vous avez toutes les activités et tâches, c'est le moment de les ordonner :

Grouper en activités : Une fois la story map initiale construite, nous souhaitons identifier des groupes que nous nommons activités. Si je dis que je peux faire X ou Y ou Z, alors nous les organisons dans une colonne comme un ensemble d'options. Ou si j'ai un groupe d'éléments liés, je les mets ensemble. Si je fais A puis B puis C de façon discrète, alors je les positionnerai probablement horizontalement.

Group-and-define-activities FR.png

Identifier les vides : Ensuite, je recherche les tâches manquantes pour ma story map. Je le fais en demandant à quelqu'un de décrire un autre scénario ou de prendre un point de vue différent (par exemple, différentes personas utilisateurs). Pendant que cette personne décrit cet autre scénario, une autre personne se tenant au tableau pointe la story map quand elle voit des éléments déjà couverts. S'ils entendent quelque chose qui manque, le reste de l'équipe est prêt à capturer la nouvelle tâche sur un autre post-it. Cela nous permet d’étoffer avec les "chaînons manquants".

Test-for-gaps FR.png

Prioriser : A ce stade, en équipe, nous examinons la story map pour établir des priorités. Dans les activités / colonnes, nous déplaçons les éléments les plus importants et les éléments les moins importants. Nous pouvons trier les éléments d’une activité et nous pouvons également créer différentes couloirs sur la story map pour différencier les niveaux de priorité (ex: Must, Should, Could).

Prioritize fr.png

Définir les Itérations : Maintenant que la story map est priorisée, nous pouvons définir les itérations ou les versions sur notre story map. Nous pouvons tracer une ligne pour la Version 1. À partir de là, nous pouvons estimer le travail avec l'équipe et peut-être affiner notre périmètre.

Define-iterations FR.png

Maintenir la story map à jour : Imaginez-vous à la première Revue de Sprint et apportez la story map (j'ai une équipe qui l’a fait sur un tableau blanc mobile) et communiquez les progrès en affichant la story map mise à jour avec les éléments marqués comme étant terminés. Les parties prenantes impliquées dans la story map n’auront-elles pas une meilleure compréhension des progrès, au lieu de leur dire que vous avez terminé 20 points sur 100 dans le backlog ? Les story maps ne sont pas uniquement puissantes pour capturer les exigences, mais aussi pour disposer d'une visibilité en continu.

Restez à l'écoute pour le deuxième article de Story Mapping, où Reese expliquera comment transformer un backlog hérité en une story map.