Les Manuscrits du PO – User Story Mapping

Démarche utilisateur en Agile

La démarche Agile trouve une majeur partie de sa raison d’être dans le fait de réfléchir les choses pour chaque “persona” (ou utilisateur final), et avec la perspective de chaque persona. Cela explique entre autres, le formalisme des users stories, définissant la valeur dans ce cadre. 

Comme nous le verrons plus tard dans l’article, être centré sur l’utilisateur sera une des clés pour la problématique de réponse à une analyse de besoins, et comment le concept de Story Mapping s’articule autour de cette problématique.

 

Qu’est-ce que le Product Backlog ?

Un des outils les plus utilisés par un Product Owner lors du développement d’un logiciel est le “Product Backlog”.  Celui-ci est composé d’une liste ordonnée de fonctionnalités, besoins ou correctifs, à réaliser, les plus prioritaire situées au début de la liste. Ces éléments sont appelés des User Stories, et vont composer ce qui est requis dans le produit. Le product backlog est l’unique source des besoins courants et des futur changements, étant ainsi évolutif dans le temps.

Comment récolter et organiser le besoin ?

Il existe de multiples façons de récolter les besoins pour un produit, et ainsi créer les premières versions d’un Product Backlog. Ce processus est en général très coûteux en temps et en ressources.

L’une d’entre elles, pourtant, est redoutablement efficace, permettant de grandement optimiser ce temps et ces ressources: Le User Story Mapping.

Le Story Mapping

C’est une pratique Agile inventée par Jeff Patton qui se veut visuelle et interactive, centrée sur la définition d’un produit, s’appuyant sur la vision des utilisateurs. C’est un moyen simple de visualiser les histoires racontées par votre logiciel.

Elle permet de:

  • Rendre visible le flux de production de valeur
  • Montrer les relations entre les fonctionnalités principales et leur décomposition
  • Aider à vérifier la complétude d’un besoin fonctionnel
  • S’assurer de la cohérence des releases planifiées

Les artéfacts d’une User Story Map

Utilisateurs (personas)
Une fiche simple définissant les types d’utilisateurs de l’application.

Activités
Elle définissent les principaux groupes de tâches effectuées par les même types d’utilisateurs, dans un même but

Squelette – Flux narratif
Usages, listés de gauche à droite, dans l’ordre temporel. Ils détaillent un peu plus les activités, tout en restant haut niveau. Ces usages peuvent être considérés comme les “Epic Stories”. Les questions à se poser pour déterminer les usage de votre logiciel ou produit:

  • Que fait cette personne avec votre produit ?
  • Que fait-elle ensuite ?


Taches – Details
Les tâches sont une décomposition des usages. Le but ici est de fournir le plus de détails possible, tout en gardant une cohérence (verticale) avec l’usage. Décomposer les tâches permet également de les regrouper, de les ajuster, de créer de nouveaux usages.

La verticalité sert ici à classer les tâches par priorité. A ajuster à tout moment lors d’un atelier de Story Mapping.

Les tâches seront la base de la création de User stories, quand il s’agira de constituer le product backlog, et démarrer les sprints.

Séparateur de releases

Une fois tout les taches récoltées et priorisées, l’étape suivante consiste à tracer une ligne horizontale servant à délimiter la prochaine release et donc, son scope.

Il est important de se concentrer sur le contenu la prochaine releases, et laisser pour plus tard le détails des releases suivantes.

L’usage est de fixer comme objectif de ne garder que 40% maximum des fonctionnalités dans la prochaine release.

Processus de création d’une Story Map

  1. Mettre en place le cadre
    1. Faire un descriptif court du produit ou du logiciel afin de cadrer et mettre des contraintes
    2. Quoi: nommer le produit, les fonctionnalités à rajouter au produit, les problèmes a résoudre
    3. Qui: nommer les différents types d’utilisateurs, établir les “personas”. Pour chaque type d’utilisateur, établir l’intérêt d’utiliser le produit
    4. Pourquoi: Décrire l’intérêt pour l’organisation d’implémenter le produit

  2. Etablir la carte de la vision globale
    1. Se concentrer sur l’histoire complète, haut-niveau sans rentrer dans les details → construire le squelette de la Story map
    2. En commençant par le type d’utilisateur le plus important pour la réussite du produit: Imaginer une journée typique d’utilisation du produit, les activités seront ainsi réparties de gauche à droite, suivant l’écoulement temporel de cette journée d’utilisation
    3. Identifier les activités, en groupant les tâches d’un même type et suivant un objectif commun. Les activités émergent généralement au fur et à mesure que l’histoire se dévoile
    4. Ajouter des types d’utilisateurs, lorsque ceux ci sont identifiés. Procéder aux mêmes actions pour ces utilisateurs et mettre à jour les tâches et activités pour ces utilisateurs

  3. Explorer
    1. Continuer de détailler les activités et découper les tâches conséquentes en sous tâches et détails d’interface utilisateur.  Ajouter, subdiviser, réécrire, réorganiser les éléments de la carte
    2. Ne pas hésiter à donner trop d’information, ou de penser en dehors du scope, l’idée est ici de récolter le plus d’information possible. Le scope sera réajusté plus tard
    3. Considerer les nice to have, les variations, les exceptions, les autres types d’utilisateurs
    4. Régulièrement relire la Story Map pour vérifier sa consistance horizontale (temporelle) et verticale (activités et sous tâches les détaillant) et mettre à jour les priorités
    5. Impliquer différentes personnes liées au produit: Business owners, développeurs, architecte, etc..

  4. Définir le scope des releases
    1. Se concentrer sur le scope de la prochaine release, en traçant une ligne le délimitant du reste des incréments du produit
    2. Se donner la contrainte de n’inclure que maximum 40% des tâches dans cette release, le reste sera distribué dans les releases suivantes
    3. Se donner plus de flexibilités sur les scope des releases suivantes, celles-ci seront ajustées dans le futur
    4. Pour chaque release, définir son objectif et impact, ainsi que les métriques de sa réussite

  5. Formaliser une vision, stratégie de développement
    1. Cette ultime étape servira à établir la première version du “Product backlog”
    2. Diviser la première release en 3 phase de livraisons:
      1. La version la plus simple et fonctionnelle du produit
      2. Une version plus riche du produit, ajustée avec les feedback
      3. Une version raffinée du produit

La suite

L’atelier de Story mapping n’est qu’une des étapes dans le cycle de vie d’un produit. Comme démontré, il permet de rapidement donner une première vision claire d’un produit.

Cette carte d’histoires, sera ensuite une base solide à la constitution du Product backlog, qui sera évolutif dans le temps. La suite, dépendra de chaque projet, de chaque produit, de chaque logiciel. Avec par exemple une décomposition en Sprint pour une project logiciel en Scrum.


Astuces

  • Ne pas être trop strict sur l’organisation temporelle
  • Faire intervenir différent types de personnes impliquées dans le produit: Business owner, utilisateurs finaux, développeur des logiciels,  etc..
  • Etre flexible sur la création de la story map: rajouter des colonnes si besoin, des séparateurs etc..
  • Ecrire lisiblement sur les post-its
  • Ne pas hésiter à ré-écrire un post-it et jeter le precedent
  • A tout moment, pendant l’atelier, prioriser
  • Des ateliers de story mapping peuvent nécessiter plusieurs heures, voire s’étaler sur plusieurs jours
  • Il est normal de devoir utiliser une espace conséquent pour lister toutes les tâches (souvent des centaines de post-its) sur différents supports: plusieurs murs, sol, tableaux etc..

 

Sources

Leave a comment

Your email address will not be published. Required fields are marked *