Advanced Story mapping

Lors du Framing Agile, nous utilisons le story mapping de Jeff Patton pour créer une première vision de notre futur backlog du produit que nous sommes en train de créer ; le framing agile va même lui rajouter des concepts complémentaires intéressants. Nous l’avons appelé l’advanced story mapping (l’ASM). Je ne peux d’ailleurs que vous conseiller de lire son livre complet (Le story mapping de Jeff Patton) qui vous explique tout détail cette excellente pratique.

Dans ce livre, je vais vous présenter le Story-mapping adapté au cadre du Framing Agile. Lors de la création de nos différents Customer Journey, nous avions en réalité commencé par définir les deux premiers niveaux de notre Story-Mapping.

Attention : si vous ne pouvez pas constituer tous les personae/customer journey car vous devez attendre des interviews, cela ne doit pas empêcher de commencer votre story-mapping avec ceux déjà réalisés précédemment. Votre ASM s’affinera lorsque vous aurez tous les éléments en main pour le faire.

Vous pouvez regarder la vidéo de La Minute Agile qui explique en vidéo comment faire un story-mapping :

Mise en place des thèmes dans notre story mapping

Pour commencer, nous allons tracer une ligne horizontale que l’on nommera “Time” ; puis nous tracerons une ligne verticale que l’on nommera “priority” (voir image ci-après).

Nous utiliserons pour cet atelier des post’it de 3 couleurs différentes afin de bien différencier visuellement les 3 types d’éléments que nous aurons : Themes, functionalities et stories.

Nous allons à présent récupérer les différents thèmes que nous avons défini avec nos Customer Journey pour les mettre sur notre story-mapping sur une première ligne :

Je n’ai pas mis tous nos thèmes sur l’image ci-dessus mais l’idée est de placer l’ensemble de nos thèmes sur cette première ligne.

L’iron triangle agile

Nous allons à présent réfléchir “agile” pour replacer l’ensemble de nos thèmes sur le Story Mapping. Repartons de l’Iron Triangle Agile qui est représenté ci-dessous.

Sur un projet agile, on peut sans soucis fixer les coûts et les délais du produit que nous désirons réaliser. Cependant pour cela, le périmètre du produit doit être variable.

Sachant que le périmètre du produit sera variable, nous allons réfléchir pour livrer les éléments qui ont le plus de valeur avant ceux qui représentent le moins de valeurs. Il est évident qu’il sera nettement plus intéressant d’obtenir des feedbacks des clients sur les pages principales de navigation du site ecommerce que sur les fonctionnalités d’authentification.

Nous allons donc reclasser nos thèmes en les positionnant de celui qui délivrera le plus de valeur à nos clients à ceux qui en délivrent le moins.

Si cette organisation peut nous sembler correcte au moment où l’on fait ce story-mapping, rien ne nous interdira de réaliser des modifications plus tard si nous nous apercevons qu’il y a encore mieux à faire. On est agile donc on n’hésitera pas à adapter ce story-mapping plus tard en acceptant de se dire que nous pouvons faire des erreurs et qu’il n y a rien de grave à cela.

Mise en place des Functionalities

A présent, nous allons mettre en dessous des thèmes, les fonctionnalités qui étaient représentées par des cadres jaunes sur les Customer Journey. Nous allons mettre ces fonctionnalités sur des post’it rouge pour bien les différencier de nos thèmes.

Nous mettrons les fonctionnalités en-dessous de leurs thèmes respectifs. Les thèmes des fonctionnalités seront toujours placés au-dessus de la fonctionnalité de gauche. Cela permet de bien identifier le thème “père” de chacune des fonctionnalités.

Voici le résultat de ce story-mapping quand on place l’ensemble de nos fonctionnalités :

Pour rappel, pour des raisons de lisibilité et de place, je n’ai mis que mes deux premiers thèmes sur l’image mais il faut faire l’exercice avec l’ensemble des thèmes identifiés lors de la création des Customer Journey. Un story-mapping peut prendre plus de 4 mètres de long sur un mur donc n’hésitez pas à prévoir de l’espace pour le réaliser.

Comme pour le placement des thèmes, nous tentons de mettre nos fonctionnalités de gauche à droite dans le sens dans lequel  nous pensons les traiter (pour livrer un maximum de valeur en premier).

Découpages des functionalities en stories

Pour la suite de cet atelier, nous allons commencer par apprendre à découper nos fonctionnalités en stories (certains les appelleront des Epics). Pour réaliser ce découpage, il faut avant tout connaître quelques règles essentielles.

Les stories doivent être INVEST

On dit que les stories doivent être INVEST. Nous allons voir à présent ce que signifie cet acronyme très répandu dans le monde de l’agilité.

• I pour Indépendante : chaque story doit être livrable indépendamment des autres au moins sur le sprint en cours.
• N pour négociable : les détails doivent être négociables. C’est pour cela qu’on écrit une story dans un langage simple compris par tout le monde.
• V pour valeur : chaque story doit apporter de la valeur business pour les métiers ou les clients
• E pour Estimable : chaque story doit être estimable par les équipes de développement ; pour cela, ces équipes doivent bien les comprendre.
• S pour Suffisamment petite : chaque story doit être bien découpée afin d’être livrée au sein d’un seul Sprint.
• T pour Testable : il faut que toutes les stories soient testables.

Je vais revenir sur cette notion d’indépendance car elle n’est pas évidente à comprendre alors qu’elle est essentielle à maîtriser.

Découpage par le MVF (Minimum Viable Feature)

Voici une technique que j’aime beaucoup pour faire ce découpage si particulier tout en respectant cette notion d’indépendance. Si nous avons un formulaire d’inscription à réaliser, nous allons définir la partie MVF (Minimum Viable Feature) de la fonctionnalité puis définir les stories d’amélioration.

Cette notion de MVF vient tout droit de la notion de MVP (Minimum Viable Product) que nous verrons plus loin au sein de cet atelier. Nous allons définir pour chacune des fonctionnalités le minimum requis pour pouvoir tester la fonctionnalité ; puis nous définirons les ajouts complémentaires non indispensables pour la tester qui seront non MVF.

Prenons l’exemple de ce formulaire représenté ci-dessous :

Il propose un formulaire simple avec quelques fonctionnalités plus avancées :

• auto-complétion de la ville par rapport au code postal
• auto-complétion du pays par rapport à la ville.

Le formulaire simple avec ses champs textes, ses titres et son bouton de validation représente le MVF de notre fonctionnalité ; en effet, il est le minimum que nous devons réaliser pour pouvoir utiliser cette fonctionnalité. On en fera une première story.

Les fonctionnalités plus avancées seront considérées comme des ajouts intéressants mais pas indispensables pour la sortie de la fonctionnalité. Ces ajouts sont en effet dépendant de la story MVF défini auparavant si nous devions la livrer au même moment. Cependant dans ce cas, nous livrerions la story MVF dès le premier lot alors que les autres seraient livrées beaucoup plus tardivement. Donc au moment où elles seront prises en charge par l’équipe de réalisation, elles seront livrables indépendamment des autres car la partie MVF sera livrée depuis quelques temps déjà.

Nous allons donc découper chacune des fonctionnalités en plusieurs petites stories si cela est évidemment possible.

Découpage sur le story-mapping

Maintenant que ces notions sont bien comprises par les participants, ils pourront créer le découpage des fonctionnalités sur le story-mapping avec des post’it jaunes.

 

Conseil : Sur ce story mapping, nous avons défini une fonctionnalité “visuel général” spécifique pour rendre cette partie totalement indépendante des pages de notre site ecommerce. Si vous ne trouvez pas de découpage à faire sur votre fonctionnalité, vérifiez que celle-ci ne soit pas déjà le découpage d’une autre fonctionnalité. Cependant, il est possible d’avoir un seul post’it story sous la fonctionnalité. Nous écrirons la même chose sur ce post’it que sur celle de la fonctionnalité pour faciliter la suite des ateliers.

Les NFR (Nonfunctional Requirement)

Rappelez-vous avant tout que le fait d’avoir des user stories indépendantes permettra aux développeurs de n’avoir aucun doute sur les estimations de celles-ci.

Cependant avec la technique que nous avons indiqué, il reste une dépendance technique forte surtout lors du démarrage du projet. Par exemple, sur notre site ecommerce 80% de nos user-stories auront une base de données. Mais sur quelle user-story, le développeur estimera la charge d’installation de la base de données ?

Pour répondre à cette question, lors du framing agile, nous allons privilégier la notion de NFR (Nonfunctional Requirement). Cela permettra de sortir ces grosses dépendances techniques et de les mettre au sein d’un item séparé.

Cette séparation sera très utile car elle permettra de traiter ces NFR lors du framing agile pour être prêt en sortie de celui-ci de délivrer un maximum de valeur dès le premier sprint.

On insèrera une première colonne spécifique NFR qui n’existe pas dans un story-mapping classique pour mettre nos dépendances techniques. On en profitera également pour y insérer les pré-requis nécessaires pour avoir tous les éléments indispensables pour pouvoir se focaliser sur la livraison de valeur en sortie du framing agile.

On y insère toujours un item “environnement de recette” pour avoir un environnement stable ; cela permettra de tester chacune des stories dès la fin de leur développement.

Définition de notre MVP ou de notre MMP

Lors de cette ultime étape du story-mapping, l’équipe va devoir faire un choix stratégique important : va-t-on définir un MVP ou un MMP ? Ce choix sera probablement dicté par le Ministry.

MVP (Minimum Viable Product)

Le MVP sera le produit minimum (voire le service) qui permettra de tester une hypothèse ou de répondre à un problème ; toute fonctionnalité non indispensable pour tester ce service ne fera pas parti du MVP.

Le MVP contiendra une grande partie des MVF défini lors du découpage de nos fonctionnalités en stories. Cependant si certaines fonctionnalités ne sont pas considérées indispensables pour tester notre produit, on n’y insérera pas les MVF de ces fonctionnalités.

MMP (Minimum Marketable Product)

Le MMP doit créer de la valeur marketing sur un des points suivants ou sur plusieurs d’entre eux :

• différenciation par rapport à la concurrence
• générateur de revenu
• réduction des coûts
• projection de la marque
• amélioration de la fidélité des utilisateurs

Contrairement au MVP, le MMP considérera que le minimum que nous mettrons en production devra aussi être le minimum marketing qu’on exigera de notre produit. Dans les grands groupes, c’est souvent cette notion qui est en réalité utilisée et non celle du MVP.

Périmètres obligatoires en première livraison 

Dans le cadre de certains produits, il sera nécessaire de définir certains éléments obligatoires pour le MVP/MMP du produit. Dans certains domaines comme le domaine bancaire, il y aura des éléments obligatoires à mettre en place pour une première livraison. Voici quelques exemples :

• obligation sécurité
• contrainte réglementaire

Définissons notre MVP/MMP sur notre story-mapping

Sur notre story-mapping, nous allons commencer par placer les stories que nous voulons à la sortie de notre produit en haut et celles que nous aimerions avoir plus tard en bas. Nous classons ensuite nos stories de la plus prioritaire à la moins prioritaire (de haut en bas) pour chacune de nos fonctionnalités.

Nous tracerons une ligne entre les deux pour définir le MVP et la release V2.

Voici un exemple de la représentation finale de ce que donnerait notre story-mapping (qui je le rappelle n’est pas complet par manque de place ici) :

Lien utile : Story mapping, a clear understanding of its creation