Rechercher
  • David Preti

Arrêtez d'écrire vos stories, parlez-en !

Dernièrement, j’ai eu l’occasion d’accompagner une équipe lors d’une formation sur l’écriture de user stories dans le domaine du développement de solutions informatiques. Pour structurer le tout, je me suis inspiré de quelques ouvrages et particulièrement du livre « 50 Quick Ideas to Improve Your User Stories ». Je vous partage le résultat de mes recherches ainsi que de mon expérience terrain.


C’est vrai que c’est un exercice qui n’est pas facile, écrire des user stories, et c’est peut-être dû au fait que, justement, nous nous concentrons trop sur l’écriture et oublions l’objectif principal d’une story.

Une story est un medium permettant une discussion entre le business et l’équipe.

Lorsque les équipes se penchent sur les user stories, j’observe souvent les remarques suivantes :

  • le PO doit écrire toutes les user stories

  • les user stories n’ont pas de standard

  • la solution de mise en place est imposée

  • la raison du développement de la fonctionnalité n’est pas claire

  • la solution technique est privilégiée au détriment de la résolution du problème

  • il n’y a pas un aspect utilisateur ou alors uniquement un rôle générique

  • il manque des éléments clefs dans la story…

Au fil du temps, les équipes se rendent compte de ces problèmes et décident d’agir (et oui, amélioration continue 😃). Elles vont essayer de définir un format type pour les stories, et s’y tenir à tout prix quelles que soient les conditions. Ainsi arrive-t-on à ce genre de résultat :

As a system I want to monitor

De la même manière, elles vont commencer à écrire le « pourquoi » nous avons besoin de cette fonctionnalité, avec comme proposition

As a system I want to monitor so that I monitor

😃 (je force un peu le trait mais nous y sommes proches parfois).

Pour terminer, les équipes essaient d’inclure un rôle pour se retrouver avec des stories qui commencent de la même manière

As a user…

L’absurdité de l’exercice, donc l’absence d’efficacité, guette. Cherchez la plus-value…

L’erreur est que nous n’abordons pas les problèmes remontés du bon point de vue. Il est nécessaire de changer de perspective. Une story est un medium permettant une discussion entre le business et l’équipe. Elle se doit de décrire non pas une nouvelle fonctionnalité mais un changement de comportement pour l’utilisateur, pourquoi nous cherchons à changer ce comportement et dans quel but.

Voici quelques idées que j’apporte pour les équipes :


Garder vos stories courtes et ouvertes

Pourquoi, selon la littérature, une story doit tenir sur une carte bristol (le 1er C pour « Card » des 3Cs) ? L’idée est qu’elle soit succincte pour rester ouverte à la discussion (2e C pour « Conversation »). Le fait d’être courte nous permet de l’intégrer dans un sprint mais aussi de la revoir sans perdre de temps, d’argent et de motivation si nous constatons que notre hypothèse n’est pas la bonne.


Une story éphémère

Et quid du 3e C (« Confirmation ») me direz-vous ? Souvent les équipes me demandent : on tourne la carte pour écrire les tests ? Il n’y a pas assez de place. C’est vrai. En fait, nous pouvons déterminer les conditions d’acceptation au dos d’une story, mais les tests devraient prendre place dans … votre outil de gestion des tests. Et oui, pour pouvoir se débarrasser d’une story à la fin de son implémentation, il est nécessaire de séparer ce qui doit persister (les tests, la documentation) de ce qui peut être jeté (les conditions d’acceptation).


Une story présentable

Une story doit pouvoir être présentée à vos clients à la fin d’un sprint. Pour cela, elle doit définir un changement de comportement de la solution pour l’utilisateur.


Tous responsables

Une question qui revient très souvent : est-ce que le PO est le seul à écrire des stories ? La réponse est NON. L’équipe qui délivre et le PO qui transmet les besoins business sont tous deux responsables dans l’écriture des stories, de les compléter suite à la discussion. Il en va de même pour les tests. Un exercice que j’ai découvert dans le livre « 50 Quick Ideas to Improve Your User Stories » : le PO est présent pour définir le qui et le pourquoi d’une story, le développement peut apporter son expérience sur le quoi ou le comment. Ceci permet à l’équipe de s’impliquer d’avantage dans la recherche de solutions pour répondre aux besoins de l’utilisateur.


Voici quelques conseils qui couvrent les 3Cs et une partie de l’acronyme INVEST. Lors d’un prochain article, je prendrai le temps de discuter d’autres aspects de la story, tels que l’estimation ou l’indépendance, par exemple.

Et vous, vous en êtes où dans votre discussion ?

Référence : https://leanpub.com/50quickideas


#userstory #agile

12 vues

©2018 by AGILEFORGE.