De l'écriture des User Stories

J'ai été sollicité récemment sur un sujet de User Story, et en y répondant, j'ai pris un peu le temps de reprendre un peu le sens de l'écriture des User Stories.

US et Agilité

Ecrire des users stories pour être agile, les écrire comme l'entend les méthodes agiles, être agile parce qu'on écrit des users stories...

Différentes choses dans ces propos me chiffonnent, j'aime à rappeler, de distinguer l'Agile (qui est de l'ordre de l'état d'esprit), des cadres de travail ou des méthodes.

Pour rappel, Scrum n'impose pas de formalisme d'échange entre le responsable produit et l'équipe.

Il préconise d'avoir un backlog, avec des éléments suffisants petits (un item doit pouvoir être réalisé en un sprint).

XP a apporté des éléments précisant un formalisme qui se veux standardisant. Aujourd'hui, la plupart des projets "agiles" utilisent ce "standard" pour échanger de l'information.

Échanger

Il faut bien comprendre qu’une US est avant tout un support d’échange, à la conversation, et non pas un livrable rédactionnel fini. Une US sert avant tout à transcrire un bout d’idée sous un format « standard » pour pouvoir la présenter aux développeurs.

XP préconise que cela tienne sur un bristol horizontal (titre, règle de gestion exprimé en tant que, je peux, afin de, et tests d’acceptation), cela donne une idée qu’en terme de contenu cela doit rester léger.

Même si cela reste un standard, ce n’est pas absolument la forme qui importe, et l’important est de savoir si finalement, grâce à cela, les équipes de développement sont en mesure de faire correctement leur travail. En soit, le travail de rédaction des US n’est qu’une étape dans le dialogue avec l’équipe pour obtenir le produit imaginé.

Pour rappel, les US doivent être INVEST (indépendante, négociable, verticale, suffisamment petite, testable), et le N de INVEST est négociable, c’est-à-dire que les développeurs doivent pouvoir demander au PO de retravailler/découper/reformuler une US, car lors de l’échange l’équipe trouve que l’US n’est pas à la bonne granularité, qu’il manque telle ou telle information, ou qu’elle n’est pas compréhensible en l’état.

Cela ne doit pas être considéré comme un livrable figé, immuable, mais bien un élément d'échange, qui peut vivre durant son cycle de vie.

Il faut être vigilant à ne pas transformer le travail de rédaction des US en ce qui s’apparentait avant à un cahier des charges, ou un dossier de spécification. Sinon on revient à un travail en silo, et du cycle en V.

Finalement, chaque US pourrait être un chapitre d'une spécification plus large, et le format ayant changé, appelé cela l'agile, alors que les usages restent toujours ceux de l'ancien monde.

Les écrits ne doivent en cas être des commandements et surtout ne jamais se substituer à l'échange verbale.

Agilité

Il faut revenir au manifeste agile, dont la 1ère valeur est individu & interaction plutôt que des processus & des outils.

La 2ème valeur indique également notre préférence en un logiciel qui fonctionne plutôt qu’en une documentation complète.

Backlog

Sur un autre sujet, il est important que le backlog ne soit pas de taille démesurée, et on ne prépare pas toutes les US en début de projet, sinon on retombe dans l’inefficace cycle en V. 

En main courante, j’encourage à ne garder qu’une vingtaine d’US finalisées (on va dire l’équivalent de 2 sprints d’avance). 

Le reste doit rester à l’état d’idée (epic, features, ....), afin de pouvoir ajuster au bon moment le besoin, et ne pas avoir besoin de repasser un temps important à corriger une spécification, ou à donner une spécification qui soit bancale (car rédigée 6 mois auparavant) vis-à-vis d’un existant qui a pu diverger.

Échanger et comprendre le besoin

Pour résumé, l’important est de se mettre d’accord ensemble (avec l’équipe de dev) sur leur besoins, sur ce qui les aide à traduire un besoin métier en un code applicatif, qui répond à vos exigences.

L’important n’est pas de passer du temps à rédiger, mais de maximiser le temps que vous avez à échanger avec l’équipe, pour qu’elle s’approprie votre besoin, le challenge, et que vous-mêmes vous vous imprégniez de leurs contraintes.

Les 3 amis

Afin de favoriser l’échange avec l’équipe et de déterminer la qualité de vos US en terme de contenu, il existe une pratique qui s’appelle le three amigos. Une fois ou deux par sprint, vous envoyez vos US aux développeurs et aux testeurs.

Vous organisez ensuite un workshop d’une heure, avec un po, un développeur, et un testeur, et vous vous concentrez sur comment tester les US (pas forcément besoin de descendre au niveau d’un plan de test).

Le but est que derrière cet échange tout le monde ait compris le besoin, car si on sait le tester, c’est qu’on a compris quel était le besoin, et parfois dans cette démarche, le po peut prendre conscience que son besoin n’est pas clair, ou trop important (pas assez découpé). Cela permet à chacun de découvrir ce qu’attend les uns les autres, et avoir les US au bon niveau en fin de compte.

A la fin

Vous êtes à la disposition de l’équipe pour qu’ils fassent au mieux leur travail, et l’équipe est à votre disposition pour produire le meilleur produit.

Pascal Ogil