Une user story est avant tout la promesse d'une conversation.
Ce concept est souvent traité à la légère dans un monde où l'écrit reste roi.
C'est passer à côté du plus grand intérêt de la pratique de user story : raconter une histoire, donc oralement, de quelqu'un vers quelqu'un.
Concrètement, comment cela se traduit-il ?
Un exemple parlant : avoir un kanban de release montrant les différentes étapes que traverse une user story. On a souvent quelque chose comme ça :
- Proposée
- Priorisée
- Prête
- Estimée
- En cours
- Acceptée
- Déployée
S'il vous manque l'étape Prête, ajoutez-là !
La promesse d'une conversation pourrait se traduire par un des points à vérifier pour passer à cette étape. Dans cette exemple, il s'agit de la dernière condition :
- La user story obéit aux critères INVEST
- Les critères d'acceptation sont exprimés en nombre suffisants
- On n'en a parlé et on reparti avec un consensus clairement exprimé
Ainsi, on a un moyen très simple de nous assurer qu'on a vraiment jouer le jeu de la user story : on coche la dernière case. Et vous verrez : parler, même de sujets qu'on pense triviaux a priori, ça change tout ! Succès garanti.
Bien sûr, ça ne suffira pas. Il faudra parler des détails plus tard. Il n'est pas rare d'entendre des équipes se plaindre que ce n'était pas assez clair à l'étape Prête et qu'on soit obligé de remettre en cause les estimations initiales. Mauvaise nouvelle (ou bonne ça dépend comment on le vit) : c'est normal car n'oublions pas que nous visons un fonctionnement Juste à temps et qu'en différant la discussion de certains points de détails, on peut s'apercevoir malgré tout que l'effort est plus important que prévu. Ce qui est efficace, c'est le feedback que procure les développements. En effet, quand on est au pied du mur et qu'on doit savoir quelle ligne de code développer, les questions posées sont alors les meilleures, celles qu'on n'aurait jamais pensé à poser plusieurs semaines avant, même en y passant des heures.