Les User Story ou comprendre le pourquoi du quoi !!!

Lors de ma dernière mission de Coaching j'ai été frappé par le peu d'usage que les PO faisaient des User Story.

Bien sûr, ils les écrivent dans JIRA mais après ?

Pendant les sessions de Grooming, elles étaient vites balayées au profit d'éléments qui semblaient plus concrets.

Pendant le Sprint Planning, plus de traces, ils ne parlaient que technique.

Pendant les Démos, elles n'étaient pas reprises comme élément de support.

Et pourtant... je pense qu'une User Story devrait être tout le temps là, avec l'équipe, afin d'apporter un support à toutes les discussions, comme une sorte de bloc note !

Peut-être la faute est à rechercher du côté du formalisme des User Story :

• En tant que
• Je veux
• Afin de

Première réflexion, personne ne parle comme ça ! Et lire une User Story de la sorte à voix haute est rarement compréhensible.




Le "Afin de" est souvent oublié car la plus part du temps tout l'accent est mis sur "Je veux" qui est présenté comme une demande non négociable.

Après plusieurs tentatives pour présenter les choses différemment, je suis arrivé au document ci-dessous que j'utilise en formation ou en atelier pour expliquer le sens et l'usage des User Story.

La User Story

Le but de la User Story est de fournir un support à la discussion avec les éléments indispensable à la compréhension du "pourquoi".

J'insiste toujours sur ce "pourquoi" car il permet de comprendre l'objectif final visé par l'utilisateur (le qui) et surtout il permet de négocier le "quoi" pour le rendre réalisable dans les temps impartis.

Le "quoi" indique ce que l'utilisateur souhaite comme évolution, ce "quoi" doit pouvoir être mis en concurrence avec les autres éléments de la User Story, car pour atteindre son objectif il est tout à fait possible qu'il y ait d'autres voies !

A cela s'ajoute des conditions (les critères d'acceptations), ces conditions nous informent des limites que le demandeur donne à sa demande.

Exemple :

- Travailleur habitant à plus de 5 kilomètres de mon bureau
- Je souhaite une voiture
- Pour me rendre plus vite et sans fatigue à mon bureau

Conditions :
- Le trajet doit prendre 20 minutes maximum
- Je ne dois pas arriver en sueur
- Le trajet ne devra pas me coûter plus de 80€ par mois

Cet exemple illustre bien la nécessité du "pourquoi", il transforme une simple demande en valeur !

Pendant le Grooming des questions doivent surgir, comme :

• La voiture est-elle vraiment la meilleure solution ?
• Pouvons nous atteindre cet objectif différemment ?
• Les conditions sont-elles réalistes ?
• Doit-on rajouter des conditions ?

Pendant le Sprint Planning, l'équipe va chercher la meilleure implémentation possible du "quoi" permettant la satisfaction de l'utilisateur.

Pendant le développement de la solution, l'équipe va garder à l'esprit le "pourquoi" et les "conditions" afin de ne pas s'égarer et d'essayer de faire le maximum avec le minimum.

La démo va servir à montrer que les conditions sont bien respectées.

La User Story devrait-être quelque chose de simple et naturel, il n'y a rien de compliqué dedans et elle ne demande pas un grand savoir faire.

C'est un recueil résumé des besoins de ses utilisateurs et des objectifs qu'ils cherchent à accomplir.

C'est un lien entre l'utilisateur l'équipe.

Quand on dit que la User Story remplace les spécifications classiques je ne suis pas d'accord... il s'agit d'autre chose, un document qui véhicule d'autres informations avec un autre objectif !