Dis Jamy, comment on fait une User Story ?

Spoiler alert, non, il ne s’agit pas ici d’apporter une réponse universelle à la sempiternelle question : c’est quoi une User Story parfaite ? Parce qu’essayer de trouver une définition générique à quelque chose d’aussi dépendant de son contexte d’utilisation, me paraît aussi prudent que d’appliquer tel quel le mode de fonctionnement pourtant déjà obsolète d’une entreprise de streaming audio.

Mais alors de quoi va-t-on parler ici ? De communication. Il me semble qu’une User Story est avant tout un prétexte à faire se parler entre elles des personnes issues du produit, et d’autres de l’opérationnel. Sans ce dialogue, n’importe quel processus va créer des frustrations d’un côté ou de l’autre. Mais je m’égare, continuons plutôt à enfoncer des portes ouvertes.

Une User Story n’est pas une documentation figée (duh)

A minima, c’est une documentation vivante, mouvante, qui évolue en même temps que peuvent évoluer nos apprentissages et nos pratiques. Certes, il est bon de figer un peu le périmètre à un moment. Voir arriver une modification urgente et vitale mid-dev peut provoquer chez certaines personnes une furieuse envie d’apparaître dans la rubrique faits divers du 20 minutes du lendemain. 

S’imposer un template figé de User Story ,c’est ignorer que la relation entre le produit et l’opérationnel est une relation horizontale, entre personnes ayant à cœur de livrer de la valeur. Et comme dans toute relation, nos attentes évoluent au fur et à mesure que nous gagnons en maturité. Alors ce “contrat tacite” que peut être une User Story doit aussi évoluer. Que ce soit en termes d’attendu ou de capacité à offrir. 

Oui, bon, ok, mais comment on fait une bonne User Story ?

Je ne prétends pas avoir de recette toute faite, tout au plus une proposition d’enchaînement. Celui-ci a dans une expérience passée, je l’espère, aidé une équipe à lever des ambiguïtés. Et par équipe, j’entends développeurs et product owner.

La première étape de cet enchaînement est une session de travail d’une heure. Quelques jours avant le rendez-vous, il est bon de laisser le temps aux futurs participants de réfléchir aux derniers sprints.

Demandez :

“Regardez en arrière. Identifiez une US ayant facilité le travail, donné un sentiment d’accomplissement (par simplicité dans cet article on l’appellera US positive). Et une qui vous a généré des blocages et/ou des frustrations (US négative)”. 

Je pose cette question autant aux développeurs qu’au product owner. Ce dernier, on l’oublie trop souvent, pouvant être mis en difficulté autant que quiconque par une US.

Lorsque la rencontre arrive, tout le monde partage ses deux US retenues. Il est très probable que dans le négatif la plupart des participants aient la même, mais moins pour le positif. En groupe, par le processus de prise de décision de votre choix (il n’est pas pertinent dans mon propos de détailler cet étape, voici quelques exemples ici) vous allez sélectionner une US positive, une négative.

Pourquoi cette User Story ?

C’est la question qu’on va se poser pour les deux US retenues. A la manière d’une écriture à quatre mains vous allez prendre en note les réponses, relancer la discussion, relever les points essentiels, etc. Je recommande de prendre des notes au format mindmap, ça permet de dégager des tendances, des points communs, des thématiques. 

Je vous invite à vous attarder sur les attentes non rencontrées. Dans un sens ou dans l’autre d’ailleurs. L’équipe de développement attendait de la part du product owner tout un tas de maquettes, mais pourquoi n’étaient-elles pas présentes ? Le PO peut alors avoir l’opportunité d’expliquer au reste de l’équipe les difficultés auxquelles il fait face. Cela permet à tous de faire preuve d’empathie. De l’autre côté du miroir, le PO peut aussi réaliser les difficultés et la pression que peuvent subir les développeurs. Il peut arriver qu’on leur demande de réaliser un travail sans toujours leur en donner tous les moyens. 

Si vous avez opté pour le format mindmap, à la fin de la discussion, vous aurez dégagé un arbre. La représentation de ce qui est attendu d’un côté comme de l’autre, les besoins identifiés, un peu comme ceci :

Mais bon, ça reste générique. Et souvenez-vous plus haut, mon amour pour ces choses là. Alors comment aller encore plus loin ?

On prend la même et on recommence

Maintenant que tout le monde autour de la table s’est entendu sur la “bonne” granularité de la rédaction des User Stories, mettons cela à l’épreuve lors d’une seconde session d’une heure. Invitez les participants à sélectionner avant la rencontre un sujet : “Je vous propose d’aller piocher dans le backlog la pire User Story. Vous savez, celle qui traîne en validation depuis des semaines ? Celle qui fait du yoyo entre done et to-do ? Ou encore celle qui a été terminée après des mois de galère”.

Au début de la séance et comme pour la précédente, sélectionnez en groupe la User Story que vous allez réécrire tous ensemble. 

Vous allez probablement observer les limites du modèle fait précédemment, qui va devenir en fait un simple guide de choses qu’il ne faut pas oublier d’aller explorer. En le remaniant avec un exemple concret qui a donné du fil à retordre à tous, on va se poser de nouvelles questions. Par exemple : “on a besoin de critères d’acceptance, mais au fond c’est quoi pour nous ?”. Ou encore : “en fait ça nous aiderait de connaître le besoin business en bout de ligne”.

Finalement, on fait apparaître des informations qu’un ou l’autre des parties présentes pensait implicite, évident, mais qui ne l’était pas forcément pour tout le monde. On se retrouve avec des mindmaps de ce type :

Et ensuite?

On recommence. Oui, régulièrement je vous invite à reproduire l’exercice. Le plus long (et le plus pénible) était de se lancer. S’il est récurrent il est alors plus fluide à dérouler : on sait déjà ce dont on veut parler. On a déjà le modèle de mindmap qui est pré-rempli. Il faudra alors mettre à jour, en fonction de ce qui a changé dans la mécanique de collaboration entre les membres de l’équipe.

Je pense important de prendre pour cette routine un exemple tiré des éléments terminés du backlog. Des réflexions purement philosophiques sur ce qu’est une User Story ne fera probablement pas avancer une équipe qui est déjà rodée, bien qu’en difficulté. Se baser sur des exemples concrets de la vie de tous les jours a plus de potentiel, je pense, pour trouver des marges de progression réalistes qui viennent adresser une problématique réelle.

À force de faire cet exercice, le product owner embarque avec lui l’équipe de développement dans ses réflexions sur les enjeux business. Les discussions tournent autour de la valeur attendue et tous s’impliquent dans les aspects fonctionnels, s’entraident et se fixent des objectifs communs. En bout de ligne, est-ce que c’est pas ça le sens d’une équipe ?