Afin de…

Voilà un bout de phrase que l’on retrouve systématiquement en fin de description d’une User Story. C’est à la suite de ce « Afin de » que sera décrit la raison d’être de la User Story, le service rendu, le besoin utilisateur. A la fin…

C’est quoi une User Story?

Une User Story est un prétexte à la discussion. Ce n’est pas moi qui le dit, c’est la définition même donnée par la méthode 3C.

• Carte : Le support qui va porter le besoin qui va passer de l’état abstrait à un élément tangible. Son existence est l’expression d’un besoin auquel répondre.
• Conversation : Parce que la Carte existe, nous pouvons discuter de ce qu’est vraiment le besoin, la façon d’y répondre.
• Confirmation : Nous aurons besoin de valider ensemble que le besoin a bien été pris en compte et que la réponse apportée est efficace. La Confirmation autorise la destruction de la Carte.

L’écriture de la User Story (US) répond aussi à un formalisme pour être efficace. Ces caractéristiques se regroupent sous l’acronyme INVEST :

•  I pour Indépendant : Chaque US peut être développée sans adhérence avec une autre. Pas toujours simple sans habitude, mais essentiel pour une planification efficace.
•  N pour Négociable.. et Négocié : Parce que le besoin a été posé, discuté, évalué, challengé, l’ensemble de l’équipe s’est accordé sur ce qu’il y avait à faire (Quoi) et la façon la plus simple de le faire (Comment).
•  V pour “valuable” (Précieux) : On sait « évidemment » la valeur ajoutée de ce besoin, sinon, on ne fait pas (Principe Agile 10) (Pourquoi)
•  E pour Estimable : L’équipe a su imaginer la complexité de cette réalisation et a toute compétence pour la réaliser sans être à la merci de paramètres inconnus.
• S pour Small (Petit), Simple : Plus c’est petit, plus on livre vite, plus on mitige le risque.
• T pour testable : Le seul élément pour que tout le monde soit d’accord sur le résultat atteint, le passage du test que l’équipe a écrit ensemble.

INVEST reprend en partie la méthode SMART qui peut aussi contribuer à l’élaboration de votre US.

Voilà, voilà, on a une belle US…

Vous n’y arrivez pas? Et bien, vous n’êtes pas seul.e! Chez toutes mes équipes, ce nouveau formalisme arrive d’abord dans l’incompréhension, voir la douleur. Nous n’avons pas l’habitude d’écrire ainsi, c’est à dire de nous poser les bonnes questions, LA bonne question : Pourquoi?

Start with WHY!

Je ne peux que vous recommander de vous tourner vers les excellentes présentation de Simon Sinek pour comprendre la teneur de l’enjeu derrière cette volonté systématique de comprendre pourquoi, et pour quoi, nous faisons ce que nous faisons.

La quête du sens

Vous tirerez toujours plus de vos équipes, de vos collaborateurs si vous les embarquez, vous les impliquez, vous donnez du sens à leur travail. C’est largement admis, et pourtant aussi largement laissé de côté… Quand je gratte un peu, je me rends compte le niveau de difficulté des PO (Product Owner, porteur du besoin Agile en équipe Scrum) par exemple à exprimer le pourquoi. Souvent éduqués à la rédaction de cahiers des charges spécifiques, exhaustifs, précis, je me rends compte qu’ils sont autant capables de traquer l’oubli de livrable que capable d’oublier la raison de la demande.

Du vécu

J’ai suivi une équipe où s’est présenté le moment de développer un outil répondant à un process essentiel très complexe. Il était aisé pour le PO de m’expliquer le process et ses différentes branches suivant les cas de figures se présentant. Par contre, il m’était (moi Scrum Master) impossible de le comprendre dans son intégralité, ni même de le retenir. Et surtout de comprendre, à quoi ça sert… Alors je demande au PO de m’expliquer ce process, d’où il vient, à qui il est utile, sa finalité. J’ai bien compris que pour beaucoup, ce process était essentiel, mais je n’arrivais pas à faire partie du groupe. Moi, c’est pas grave, je suis Scrum Master. Que je comprenne… ben on s’en fout un peu! Le souci c’est que l’équipe de devs développe sagement quelque chose qu’elle ne comprends pas non plus. Et ce n’est pas force d’essayer. Mais il faut constater que plus les US se succèdent, plus le code devient consistent, et moins on a l’impression d’avoir avancé. Et moi qui persiste sans cesse à demander « pourquoi on fait ça? ».

Entendons nous bien. Quand je demande le pourquoi, j’ai souvent une réponse. Mon souci, c’est que la réponse ne m’exprime pas un besoin utilisateur « réel », un besoin qui produise de la valeur. C’est une réponse qui fait suite à la réaction du système qui attend d’être alimenté. Vous avez compris où je voulais en venir. Après 2 mois de discussions autour de ce sujet, avec le PO mais aussi les utilisateurs, il est enfin apparut que ce process, établi en son temps pour de très bonnes raisons, s’est adapté aux évolutions de l’entreprise pour perdurer et rendre toujours le service pour lequel il avait été inventé et alimenter l’activité des personnes dévolues à ce process… Sauf que la raison d’être avait disparu en même temps que les évolutions de l’entreprise! On avait juste perdu le sens de ce que l’on faisait.

Afin de… c’est la génèse!

Je vous invite à systématiquement mettre en première réflexion de la rédaction de votre US la notion du « Afin de ». Vous avez sûrement appris qu’une bonne US s’écrit ainsi :

En Tant Que …
Je Peux …
Afin De …

Vous avez vu? Ca ressemble à une checklist! Et pour peu qu’on ait bien intégré que l’on priorise du haut vers le bas, et bien le « Afin De » peut même disparaître. On a l’essentiel avec En Tant Que et Je Peux.

Ce qui a déclenché l’écriture de votre US, c’est un besoin. Est-ce un besoin utilisateur? un besoin du système, voir un besoin systémique?

Oui, souvent c’est difficile d’écrire le Afin De. C’est aussi difficile de ne pas faire en sorte qu’il reprenne exactement le Je Peux. Super! Vous avez devant vous un signe que vous n’êtes pas en train de décrire le vrai besoin. Parce que si c’était le cas, si vous répondiez vraiment à un vrai besoin d’un vrai utilisateur, votre écriture serait fluide, limpide, naturelle. Si ce n’est pas le cas, vous êtes probablement en train de décrire une solution, et cela devient plus difficile de la justifier sur la base du besoin utilisateur.

Commencez par Afin De, et ne passez surtout pas à la suite tant que vous ne saurez pas à quoi vous répondez, c’est la meilleure façon de ne pas répondre n’importe quoi 😉

Afin d’être capable d’écrire des User Stories qui portent une réelle valeur pour mes utilisateurs
En tant que membre responsable de l’équipe soucieux de livrer toujours le maximum de valeurs aux utilisateurs
Je peux m’assurer que mes User Stories soient toujours guidées par le réel besoin de mes utilisateurs.

Ça a de la gueule non?

Enfin, pour créer de la valeur plus que des spécifications, je vous partage une vidéo sur le sujet :

Et bien sur, pour toutes vos demandes de coaching, individuel ou collectif, il suffit de prendre rendez vous 🙂