Pratiques pour bien découper des user stories

Dans l’agilité, savoir bien découper ses US, c’est le nerf de la guerre. C’est une compétence qui s’apprend mais qui demande du travail. Heureusement, c’est quelque chose qui peut se faire à plusieurs.

Attention : il existe plein d’autres articles sur comment découper, prenez le temps de les lire. Celui-ci vient en complément.

Des petites stories : un problème d’ordre 1

Plus les stories sont grosses, plus on aura de problèmes : Incompréhensions, ambiguïtés, oublis, erreurs… Et aussi stress pour finir dans le sprint, ce qui entraîne d’autres problèmes.

Les grosses stories empêchent aussi l’équipe de réagir avec agilité : quand on doit gérer un imprévu, il y a très peu de créneaux disponibles entre deux stories, ce qui force en général à s’interrompre dans sa tâche. Et ça entraîne des pertes de focus, de temps et d’autres erreurs.

La taille idéale de story c’est quand un développeur peut commencer et finir 2 ou 3 stories à la suite dans une même journée.

C’est l’étoile du Nord. C’est l’objectif que doit se donner chaque product owner : apprendre à découper ses stories jusqu’à atteindre la taille idéale.

Bien sûr, ce n’est pas le but. On demande au PO de délivrer un projet. Mais comme pour un musicien : si le but c’est que la musique soit bien, savoir bien jouer de son instrument est quand même un sacré atout.

Conseil n°1 : Partez des fonctionnalités

Un bon moyen de mieux voir comment découper les user stories, c’est de faire la part des choses entre la fonctionnalité et la user story.

La user story est un élément temporaire et arbitraire qui n’a de sens que parce qu’il nous aide à fluidifier notre réalisation. Une fois la story terminée, elle n’a plus de raison d’être, comme une goutte d’eau qui remplit un verre.

La fonctionnalité est l’élément le plus petit qui a un sens pour toutes les parties concernées par le projet / produit. C’est la fonctionnalité, c’est à dire un changement dans le comportement de l’utilisateur, qui apporte de la valeur, c’est elle qu’on va marketer.

Note : je n’utilise jamais les Epic, parce que ça n’a pas vraiment de sens pour moi. C’est un groupement d’user stories mais sans focus sur la valeur, donc moins intéressant que la fonctionnalité.

Parfois les fonctionnalités seront la taille d’une seule user story, parfois ça représentera un certain nombre de sprints ou sera répartie sur plusieurs équipes.

Bien souvent, en découpant la fonctionnalité en user stories, on verra apparaître une hiérarchie dans l’importance et l’intérêt des éléments. Ce qui aidera à la priorisation et donnera souvent lieu à une réduction du périmètre.

Prenons pour exemple une fonctionnalité de livraison en point relais. On souhaite offrir cette nouvelle possibilité aux clients pour essayer de réduire le taux d’abandon de panier (c’est la valeur qu’on cherche à capter). Une partie de cette fonctionnalité va concerner le choix du point relais.

Dans l’image on peut voir un exemple de page complète de choix de point relais. Encadré en rouge, on voit différent composants, qui peuvent être ajoutés au fur et à mesure. Chaque composant est un axe potentiel de découpe.

Bonus : en découpant, on va très vite voir se profiler une priorisation. Dans notre cas, on peut très bien commencer la fonctionnalité avec un simple choix entre trois relais près de chez le client. En livrant seulement cette partie, on pourra valider que les clients utilisent bien la fonctionnalité et on pourra constater l’incidence positive sur le taux d’abandon. Ensuite, on pourra ajouter progressivement des éléments pour capter un maximum de la valeur.

Un autre avantage de toujours commencer par la fonctionnalité plutôt que de se pencher directement dans les user stories, c’est la vision globale : en se positionnant du point de vue de chaque segment d’utilisateur, on fera apparaître leurs interactions particulières, et ça mettra en avant d’autres axes potentiels de découpe.

Conseil n°2 : Pensez INEST

Découper les stories c’est compliqué. D’autant plus quand on se base sur un standard qui n’est pas adapté à la situation.

On apprend tous l’acronyme INVEST pour caractériser le minimum acceptable en terme de story. Pour simplifier : on doit imaginer que chaque story est livrable en production immédiatement après être terminée et apporte de la valeur à l’utilisateur.

Or, dans 99% des entreprises aujourd’hui, on ne fait pas de continuous delivery. On ne livre pas chaque user story une fois qu’elle est finie.

Et on a du mal à attribuer de la valeur à chaque user story. Il suffit de regarder les “afin de” de chaque story pour s’en rendre compte.

Donc on s’embrouille, on se dit “ça n’a pas de sens de découper encore plus la story” et “on ne peut pas livrer sans avoir géré tous ces cas”. Et on se retrouve avec des trop grosses stories.

Ce que je conseille dans ces cas là, même si ce n’est pas orthodoxe, c’est de travailler la valeur (le V)  au niveau de la fonctionnalité et de faire des stories INEST, autrement dit : des petites stories qu’on peut tester au niveau fonctionnel / utilisateur.

En pensant INEST, c’est à dire à des petits éléments testables et incrémentaux, chaque règle fonctionnelle, chaque cas, devient un axe potentiel de découpe. On peut quasiment se dire que chaque test fonctionnel est un axe de découpe.

Attention par contre, ça ne vous aidera pas à vous améliorer sur la démarche produit, mais dans une entreprise où votre rôle c’est de dérouler une roadmap déjà établie, c’est parfait.

Conseil n°3 : Utilisez cet atelier découpe (3 Amigos + Example mapping + TIER)

Un excellent moyen pour mieux découper les fonctionnalités en petites user stories, c’est de ne pas le faire tout seul. Cet atelier à plusieurs est assez simple à mettre en place et offre des résultats immédiats et très intéressants.

L’atelier

L’objectif de cet atelier est de faire émerger de nombreux axes de découpe.

Idéalement, il faut déclencher cet atelier après avoir dégrossi la fonctionnalité avec les experts fonctionnels, l’archi et l’UX, mais avant d’avoir commencé les spécifications et les maquettes.

Pour les premières fois, ne vous mettez pas de limite de temps. Par la suite, vous aurez l’expérience pour savoir combien de temps cet atelier vous prend.

Doivent être présents : le product owner, au moins un développeur, au moins un testeur et l’ux, s’il y en a un dans l’équipe. Parfois vous voudrez aussi inviter un architecte.

Dans un premier temps, le PO va présenter la fonctionnalité : ce qu’on veut faire, pourquoi on veut le faire, qu’est ce que ça apporte aux utilisateurs, qu’est ce que ça apporte à l’entreprise, qu’est ce qui nous permet de croire que cette fonctionnalité va apporter ce qui est prévu etc.

Ensuite, ensemble, vous allez essayer de lister tous les cas possibles. Une grille utile pour penser aux cas, c’est de suivre TIER : Typical, Interesting, Edgy, Risky.

Passez ensemble sur tous les cas normaux, prenez le temps de faire un focus sur les cas vraiment intéressants, posez vous la question “qu’est ce qui se passe si … ?” pour trouver les cas à la marge, et enfin prenez garde à identifier les situations risquées.

En listant tous les cas, vous allez voir émerger des groupes : ce qui est indispensable, ce qui est bonus, ce qui est hors scope pour l’instant ou définitivement. Vous allez aussi avoir un meilleur aperçu de la complexité. Et enfin vous allez lever un certain nombre de questions qu’il vaut mieux se poser à ce moment là qu’une fois la réalisation démarrée.

C’est important de voir large pendant l’atelier et d’élaguer ensuite : ça permet d’avoir une vision d’ensemble et de pouvoir définir explicitement le périmètre.

En plus d’une liste d’axe de découpe, vous allez produire des éléments qui vous aideront à écrire les spécifications et les tests dans cet atelier, ce qui est un bonus intéressant.

Pour plus d’infos sur comment mener ce genre d’atelier, je vous conseille de lire ces articles sur les 3 amigos et sur l’example mapping.

Après l’atelier

Dans cet atelier vous allez produire un certain nombre de cas. Ce sont déjà des axes de découpe. Certains cas seront ensuite à découper plus finement en suivant INEST si vous sentez qu’ils sont assez large.

En sortant de l’atelier, vous aurez en main assez d’éléments pour commencer à prioriser les cas, et être capable de faire la part entre ce qui doit absolument sortir le plus vite possible et les différents étapes suivantes si la fonctionnalité marche.

Cette priorisation aidera le PO et l’UX à mieux concevoir la fonctionnalité, en prenant en compte le caractère incrémental de la solution.

Pour prendre un cas concret, si on revient sur la page de choix de relais colis :

• Si on a prévu la solution et les écrans en prenant tout en compte, mais que finalement on ne met pas en place la carte, le résultat risque d’être bancal, avec un gros trou au milieu de la page.
• Si on prend en compte le fait que les éléments de confort seront rajoutés progressivement, on peut prévoir à l’avance de faire un écran qui s’adaptera au fur et à mesure.

---

Bonus: Arrêtez avec “En tant que … afin de”

Le but de cette phrase rituelle, que tout le monde connaît, c’était de vous forcer à penser à deux choses très importantes.

Malheureusement, dans la plupart des cas, personne n’y fait attention. N’y trouvant aucun intérêt, les PO vont l’écrire à la va vite, et les développeurs ne vont même pas la lire.

Pourtant, vous forcer à penser à ces deux choses, c’est vital. Ce sont des informations qui aident à faire les bons choix pendant les 1000 moments où il faut prendre des micro décisions, pendant l’écriture des spécifications, le développement ou les tests.

Donc je vous propose de créer dans votre template d’user story un cadre dans lequel vous allez répondre à deux questions : Pour qui ? et Dans quel but ?

Pour qui ? Quel type d’utilisateur va utiliser ce que vous allez produire ici ? Il y a plusieurs avantages à répondre à cette question :

• Ça vous permet de vous mettre à sa place, et de prendre en compte ses particularités. On ne va pas penser l’US de la même manière pour un administrateur dans son bureau ou pour un jeune sur son appli mobile.
• Si vous êtes tentés de mettre plusieurs types d’utilisateurs, c’est qu’il y a probablement un axe de découpe.
• Enfin, on arrêtera de voir “En tant que PO, je veux …”. Et c’est une "bonne chose ©".

Dans quel but ? Qu’est ce qu’on apporte à l’utilisateur et qu’est ce qu’on apporte à l’entreprise ? Bien trop souvent, la partie “afin de” est carrément zappée. Pourtant, partager et mettre en avant l’intention fait gagner du temps à tout le monde :

Si le but c’est de permettre à l’utilisateur d’aller plus vite, alors peut être ces 50 nouveaux champs ne sont pas la bonne idée ? Si le but c’est d’augmenter le taux de conversion, alors peut être qu’il ne vaut mieux pas rendre cette étape obligatoire ?

Au final, avec ce cadre, vous atteindrez le bon objectif, sans tomber dans le piège du rituel.