On ne peut pas définir ce qu'est une « bonne user story »… Et ce n'est pas grave

Pourquoi le product backlog ?

Produit : coût et valeur dans un backlog

Pour définir le product backlog, j’aimerais proposer une définition assez simple de ce qu’est un produit. Un produit est tout ce qu’une entreprise peut fabriquer pour apporter de la valeur à un client et obtenir un paiement en retour. Il existe bien sûr de nombreuses variantes : l’utilisateur peut être ou ne pas être le client, le paiement peut venir ou non de l’utilisateur ; mais cela suffit pour raisonner sur le produit lui-même, son coût pour l’entreprise et sa valeur pour le client.

L’élément essentiel qui manque à cette description, c’est le temps. Le produit ne peut pas être construit instantanément : il doit y avoir un processus où il est en quelque sorte « découpé » en plusieurs parties distinctes, qui sont ensuite implémentées.

Tout ne doit pas être Agile

Dans le schéma précédent, je n’ai pas supposé que la gestion produit était Agile. On peut très bien définir un processus en cascade (waterfall), dans lequel :

L’objectif du produit est défini par les dirigeants, les business analysts, voire le client
L’expérience utilisateur attendue est complètement définie et documentée
Chaque étape de l’implémentation est planifiée
Ce n’est qu’alors que le développement commence
Et le produit est livré une fois terminé

Ici, le rôle des éléments du product backlog est de :

Définir toutes les tâches pour l’équipe de développement
Estimer leur complexité, leur temps de développement ou leur budget
Planifier en fonction des dépendances entre éléments
S’assurer que la somme des éléments produira bien le produit attendu
Surveiller à tout moment que le projet est dans les temps

Ce processus n’a rien d’Agile, mais on peut voir que les éléments du product backlog pourraient tout de même être appelés des user stories s’ils étaient écrits du point de vue de l’incrément de valeur pour le client. Pour être très clair : on peut écrire « en tant que… je veux… afin de… », on peut appeler ça une user story, et ne pas être Agile pour autant. L’Agilité se définit par des principes, pas par des techniques.

Dans la suite de cet article, on ne considère les user stories que dans un contexte de méthodologie Agile.

La « user story Agile »

Individus, interactions et collaboration avec le client

Agile ou pas, nous avons vu qu’un objectif essentiel d’une user story est de représenter une tranche du produit qui peut être implémentée par l’équipe de développement. Reste à définir quelles informations l’on veut dans cette « description de tranche », comment elle est créée, comment elle est utilisée.

Une caractéristique essentielle d’une user story Agile est qu’elle doit permettre des interactions entre l’équipe de développement, l’équipe produit et le client. Puisque nous n’utilisons pas une méthodologie en cascade, nous n’avons pas besoin de rédiger une user story complète, et surtout nous ne devons pas rédiger une user story complète avec tous les détails d’implémentation. Nous perdrions tous les bénéfices de l’approche Agile.

Nous voulons que le client discute la user story : c’est le meilleur moyen de s’assurer que chaque tranche augmente la valeur, du point de vue du client
Nous voulons que l’équipe de développement discute la user story, afin de bien en comprendre l’objectif et de produire les meilleures solutions techniques pour l’atteindre

Cela signifie qu’une user story n’est pas un morceau d’information figé, mais qu’elle est à la fois le résultat d’interactions et le support qui encourage ces interactions. C’est le rôle du product owner de faire vivre ces stories et de les aider à grandir grâce à la collaboration.

Priorités et feuilles de route, ou s’adapter au changement

J’ai souvent lu qu’un des objectifs essentiels d’une user story est de donner une estimation du travail à fournir par l’équipe de développement, afin de pouvoir établir des feuilles de route et planifier.

The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks

— extremeprogramming.org

Nous voulons des feuilles de route, nous voulons savoir quand les choses seront faites, nous voulons préparer les étapes suivantes. Bien sûr, l’équipe marketing veut connaître la date de sortie pour promouvoir la prochaine version du produit. Bien sûr, les business analysts veulent savoir quand nous allons obtenir un retour sur investissement.

En même temps, nous voulons pouvoir répondre au changement, mettre à jour le product backlog avec de nouvelles priorités, réagir à tous les retours clients que nous avons reçus.

Cela semble contradictoire. Parce que ça l’est. Les contournements habituels sont :

Les feuilles de route hiérarchiques : plus de détails et plus de confiance à court terme
Les feuilles de route temporaires : elles doivent être constamment mises à jour pour répondre aux changements
L’absence d’engagement : il doit y avoir un disclaimer sur ce qui est, et ce qui n’est pas, un engagement

C’est une autre différence entre la gestion produit et la gestion de projet. Le chemin ne peut pas être connu à l’avance, la feuille de route évoluera, et c’est encore une fois le rôle du product owner de maintenir l’ensemble des user stories : le product backlog.

Tant de frameworks

Les principes INVEST

L’acronyme INVEST a été inventé par Bill Wake pour déterminer ce qu’est une bonne user story et ce qu’elle n’est pas. Il est toujours largement cité.

But what are characteristics of a good story? The acronym “INVEST” can remind you that good stories are:

I — Independent N — Negotiable V — Valuable E — Estimable S — Small T — Testable

— xp123.com

L’indépendance signifie que chaque user story pourrait être implémentée indépendamment. Bien sûr, ce n’est pas toujours possible, mais quand ça l’est, c’est une bonne qualité.

Une user story négociable est une user story dont les détails ne sont pas encore définis et sont censés émerger des discussions entre l’équipe de développement et le client. Bien sûr, de nombreuses notes peuvent être ajoutées à la story à mesure que de nouvelles informations sont découvertes.

Une story doit avoir de la valeur. C’est la caractéristique la plus importante d’une user story. Elle doit être une tranche du produit qui augmente la valeur (du point de vue du client, comme toujours). C’est véritablement la raison d’être d’une user story.

Une story devrait être estimable, c’est-à-dire qu’on devrait pouvoir deviner combien de temps il faudra pour l’implémenter. Cela contredit la négociabilité : si nous ne savons pas quoi ni comment nous allons implémenter, nous ne pouvons pas prédire le temps que cela prendra.

A note of caution: Estimability is the most-abused aspect of INVEST

— xp123.com

Une story devrait être petite. Cela rejoint le caractère estimable, mais seulement comme un seuil : une story est soit trop grande, soit suffisamment petite pour être gérée efficacement.

Et enfin, une user story devrait être testable. Le premier point est d’éviter la dette technique avec des tests unitaires, d’intégration et de régression. Cela signifie aussi que nous pouvons définir des tests fonctionnels et d’expérience utilisateur. Nous devons pouvoir décider très clairement si la valeur de la user story a été ajoutée ou non. Être bien définie et testable sont souvent deux caractéristiques liées.

Tant de frameworks, tant de plaintes

Les frameworks en général peuvent être de très bons outils :

Ils peuvent nous guider quand on ne sait pas par où commencer
Ils peuvent être suffisamment ubiquitaires pour faciliter la communication à travers des modèles partagés
Ils peuvent garantir qu’aucune partie du processus n’est oubliée, chaque étape est documentée
Ils peuvent garantir la cohérence de notre travail, en utilisant toujours le même modèle
Ils peuvent améliorer l’efficacité, en évitant de réinventer la roue

Alors pourquoi y a-t-il tant de frameworks en concurrence s’ils sont censés apporter la solution complète ? Par exemple, il existe au moins 9 frameworks de priorisation bien connus et largement utilisés (productcompass.pm). Ils semblent tous très raisonnables ; ils sont tous du bon sens. Aucun n’est parfait, sinon les autres auraient été oubliés. Aucun n’est assez bon, sinon nous aurions cessé d’essayer d’en créer de meilleurs. Il y a des inquiétudes et des plaintes à propos de chacun d’eux.

De même, il n’y a pas de moyen évident de suivre les principes INVEST. Par exemple, que faire d’une user story « pas-assez-petite » ? J’ai vu de nombreuses variantes :

On peut essayer de la rendre plus petite en supprimant tout ce qui n’apporte pas de valeur
On devrait la découper en plusieurs user stories
On devrait considérer que la user story est un épique contenant des user stories
On devrait organiser les user stories par épiques et par thèmes

Toutes ces idées ont du sens. Mais toutes contredisent d’une manière ou d’une autre la caractéristique d’indépendance. Si on planifie un épique complet au lieu de choisir uniquement les user stories à haute priorité, est-ce acceptable ? Si on a besoin de l’infrastructure avant de déployer une fonctionnalité, y a-t-il vraiment un moyen de contourner cela ? Est-ce que ça vaut la peine d’essayer de reformuler juste parce qu’un framework le dit ?

Le product backlog, par nature, ne peut pas être homogène. C’est normal, il faut apprendre à vivre avec : cela veut simplement dire que le product owner doit le maintenir. Chaque choix que l’on fait est un compromis.

Peut-on être Agile ?

Suivre un framework n’est pas une finalité

Appliquer aveuglément des frameworks est extrêmement dangereux. Ce sont des outils, des techniques, et ils ne sont utiles que si nous nous rappelons pourquoi nous les utilisons en premier lieu.

J’ai la même opinion en ingénierie logicielle, où il existe beaucoup de frameworks et de bibliothèques. Les frameworks sont généralement des solutions de bout en bout pour un problème donné : par exemple, un framework web gérera le serveur HTTP, les endpoints d’API REST, les connexions à la base de données… Nous n’avons qu’à ajouter quelques vues pour définir le contenu et brancher notre base de données. À l’autre extrémité, les bibliothèques ne fournissent que des outils pour des tâches spécifiques : bibliothèques de connexion à des bases de données, bibliothèques de conception d’API… Nous devons encore les faire fonctionner ensemble, et nous contrôlons chaque partie que nous utilisons.

Le principal danger des frameworks, c’est que parfois ils nous conduisent à modifier plusieurs parties du processus, juste pour qu’une partie s’adapte au framework. Cela peut parfois être très insidieux, et il faut être très prudent pour ne pas obéir aveuglément aux frameworks. Nous ne devrions pas adapter notre processus aux frameworks ; au contraire, nous devrions les utiliser comme des outils, sans nous y attacher, afin de pouvoir en changer dès que cela a du sens, afin de garder le contrôle de nos objectifs.

Nous devons nous rappeler pourquoi nous voulions des user stories.

Nous voulons des choses différentes

Continuous discovery — Le product backlog est le résultat du processus de continuous discovery, dans lequel on explore les opportunités d’augmenter la valeur. Les user stories qui en résultent doivent capturer ce qu’il faut ajouter au produit, d’un point de vue externe (du point de vue de l’utilisateur). Ces user stories ne sont pas gravées dans le marbre, elles sont faites pour engager la discussion, avec le client, avec l’équipe de développement, avec le designer.

Priorisation — Les user stories servent à prioriser le travail à faire. Ce sont les briques élémentaires du produit, et il faut les prioriser. Comme nous l’avons vu, il y a de nombreuses façons de le faire, mais au final, il faut bien une forme de story map où l’on peut tirer un trait séparant les user stories retenues pour la prochaine version. Il suffit de comparer les user stories entre elles pour définir priorités et complexités.

Continuous delivery — Les user stories servent à guider l’équipe de développement sur ce qu’il faut construire. Elles devraient donner une explication claire du pourquoi l’on veut construire quelque chose ; l’expérience utilisateur attendue et la valeur apportée au client doivent être véritablement limpides pour l’équipe de développement. Ce n’est qu’une fois qu’ils ont toutes ces réponses qu’ils peuvent choisir la meilleure solution technique pour intégrer la user story au produit, augmentant ainsi effectivement la valeur du produit.

Quand on réalise qu’on manipule les user stories avec de nombreux objectifs différents, il devient évident qu’on ne peut pas créer « la seule bonne façon de les écrire », car la meilleure façon dépend de ce qu’on attend d’elles. Il est normal d’avoir plusieurs vues sur les mêmes user stories. De plus, elles sont faites pour évoluer. En phase de discovery, toute hypothèse testée doit contenir les informations nécessaires pour tester sa valeur, ni plus ni moins. En phase de delivery, toute information demandée par l’équipe doit avoir une réponse, même des détails qui n’étaient pas nécessaires à la priorisation de la story.

Plutôt que d’essayer de construire le product backlog parfait avec des user stories parfaites, je pense qu’il faut reconnaître qu’il y a différents usages du backlog, différentes vues où l’information présentée n’est pas la même.

Il nous faut de la gestion produit

Je n’ai pas donné de définition de ce qu’est une « bonne user story », et… tout mon propos est de soutenir que ce n’est pas grave. Alors, que faire ? Peut-on oublier complètement les user stories ? Bien sûr que non.

Les user stories sont très utiles quand elles permettent les interactions entre équipes, quand elles permettent de définir un MVP pour tester une idée, quand elles permettent de prioriser le prochain sprint ou la prochaine version, quand elles encouragent les développeurs à poser des questions aux clients. Aucun framework ne garantira jamais cela : c’est le travail difficile du product owner de le faire. Je serais particulièrement prudente avec tous les « méta-frameworks » où l’on peut organiser les user stories par catégories (techniques, fonctionnelles…) et par portée (épiques, thèmes…) : on peut rapidement se perdre dans des détails techniques qui n’aident ni la discovery ni le delivery.

Nous devrions utiliser tous les outils dont nous disposons, mais uniquement dans la mesure où nous pouvons vérifier qu’ils nous aident à atteindre l’objectif. La qualité d’une user story n’a que très peu à voir avec ce qui est écrit sur la carte ; son succès ne peut se mesurer qu’aux interactions et aux collaborations qu’elle a créées.