Story Mapping (technique externe et qualitative)

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Daniel Zacarias
Source : 20 Product Priorization Techniques: A Map and Guided Tour


Traducteur : Fabrice Aimetti
Date : 12/08/2018


Traduction :

Article de référence : Tableau périodique des techniques de priorisation produit

Les Cartes de Story ont été introduites pour la première fois par Jeff Patton dans cet article de 2005 et ont été suivies par une autre qui décrit son expérience la plus récente. Les deux sont d'excellentes lectures que je ne peux que fortement vous recommander de lire.

L’idée principale des Cartes de Story est que les backlogs de produits sous forme de liste unique constituent un moyen épouvantable d’organiser et de hiérarchiser le travail à effectuer. Une structure plus riche est nécessaire.

De manière très générale, une Carte de Story est organisée comme suit :

  • Il y a un axe horizontal qui représente la séquence d'utilisation ;
    • Les user stories (ou "tâches") sont placées le long de cet axe, dans l'ordre dans lequel elles sont effectuées par l'utilisateur ;
  • L'axe vertical représente la criticité ;
    • Les user stories (ou "tâches") sont organisées verticalement selon leur importance (de haut en bas) ;
    • Des stories de même importance peuvent être conservées à la même hauteur, mais gardez à l'esprit qu'en général, il est important de différencier l'importance relative des stories pour pouvoir créer de meilleurs plans de release.
  • Les groupes de user stories associées peuvent être regroupés en tant qu'Activités:
    • Créez une ligne verticale pour séparer les groupes de stories des autres;
    • Par exemple, une activité peut être "gestion du courrier électronique", avec "envoyer un courrier électronique à une ou plusieurs adresses" en tant que tâche utilisateur ;
    • Les activités se situent au-dessus de l'axe vertical et ne s'inscrivent pas dans une séquence d'utilisation, elles sont "juste là" - ces activités constituent les principaux attributs du produit et ne peuvent pas être hiérarchisées (pensez "vous ne pouvez pas donner la priorité au moteur d'une voiture par rapport à ses roues").


Story-map-1024x758.png
© Daniel Zacarias - Folding Burritos

Ce type d’organisation du backlog présente de nombreux avantages, mais les plus importants pour la priorisation et l’exécution sont les suivants :

  • C'est un outil visuel qui permet aux clients, aux parties prenantes et aux membres de l'équipe de développement de partager une compréhension commune de ce que fait le système ;
  • Il définit très clairement la manière dont les itérations du produit sont séquencées de manière incrémentale, fournissant des releases tout à fait opérationelles avec une sophistication croissante - tel est le concept du squelette ambulant (NdT : walking skeleton) d'Alistair Cockburn.
    • Pour définir des releases, créez des lignes horizontales le long de la carte, en sélectionnant des stories avec des niveaux de criticité équivalents ;
    • Cela conduit à terminer les releases du produit de bout en bout et par conséquent à accélérer la livraison et la validation du marché (ce qui est crucial au stade MVP).


Story-map-release-1024x655.png
© Daniel Zacarias - Folding Burritos

À mon avis, le principal inconvénient de cette structure (et du temps nécessaire pour la créer et la préparer) est qu’elle est trop lourde pour des projets ou des produits dans des contextes très dynamiques. En d'autres termes, lorsque la visibilité sur la forme future du produit n'est pas grande (par exemple, sous 3 à 6 mois), je préfère une approche différente (mais en relation).