Qu’est-ce qu’une bonne user story ? Est-ce un petit morceau de spécifications fonctionnelles ? Quel est le niveau de détail d’une user story ?

Beaucoup d’articles traitent de la construction des user stories mais j’ai récemment compris comment celles-ci expriment les valeurs de l’agilité. J’aime bien le fait qu’une user story soit définie comme une invitation à la communication ; comme un outil de conversation et de collaboration. Donc une user story n’est pas un petit bout de spécifications ; inutile d’essayer de tout préciser sur un petit bout de post-it. Cependant, la user story doit permettre de développer un logiciel ou construire un produit qui correspond aux besoins de l’utilisateur. J’ai récemment suivi un MOOC sur la construction des user stories selon les besoins des utilisateurs que j’ai trouvé intéressant et que je souhaitais partager avec tous ceux qui doivent construire un backlog de stories : ‘Getting Started: Agile Meets Design Thinking’ sur Coursera. Alexander Cowan et son équipe nous apprennent dans ce MOOC comment construire de belles user stories en se basant sur l’expérience utilisateur et sur le Venture Design Process.

Le Processus est très bien défini dans le site précédent mais voici pour ma part les quelques éléments que j’ai choisis de retenir selon mon expérience :

Les Personas, quand ils sont construits de manière rigoureuse, permettent de mieux comprendre les besoins utilisateurs. Ils constituent le point de départ du processus. Les Personas sont en général élaborés lors du cadrage du projet et permettent ensuite d’écrire les premières stories du backlog. Quand ils sont enrichis et utilisés tout au long du projet, les Personas sont une véritable source d’inspiration pour définir les user stories.

• Afin de vous aider à construire les user stories à partir des Personas, vous pouvez commencer par exprimer des scénarios décrivant les problèmes auxquels font face les Personas et les alternatives qu’ils ont trouvées pour les résoudre .
• Vous pouvez ensuite proposer des solutions qui apporteront une valeur ajoutée par rapport aux alternatives.
• Puis vous pouvez construire des prototypes sous forme de storyboards pour expliquer la solution et sa valeur ajoutée. Ceci vous permet aussi de revenir et d’affiner votre proposition. L’outil StoryBoardThat permet de construire rapidement des storyboards efficaces qui vous permettront d’expliquer vos solutions.

Quand on respecte rigoureusement ces étapes, on se concentre davantage sur la compréhension des besoins utilisateurs que sur la mise en oeuvre de la solution. Et c’est là que cela devient intéressant. Pourquoi ?  Et bien parce qu’on va éviter le syndrome du « bouton bleu ».  Le syndrome du « bouton bleu », c’est quand on obtient une story du type : « en tant que.. je veux appuyer sur le bouton bleu afin [d’effectuer une action]. « Cette story est précise », me direz-vous ? Oui, un peu trop précise! Cette story ne laisse à l’équipe de développement et au designer, aucune chance d’exprimer leur créativité et d’être force de proposition :

• Aucune chance d’être force de proposition car on n’a pas la clause qui exprime la plus-value apportée à l’utilisateur.
• Aucune chance non plus de proposer la solution technique qui permettrait de réaliser la fonctionnalité exprimée.

Vous serez d’accord pour reconnaître que cette story laisse peu de place pour la confiance et la collaboration des personnes. Cette story construite selon le très célèbre format, « en tant que [] je veux [] afin de [] « , ne respecte pas les valeurs de l’agilité et peut être démotivante pour les équipes. Le format ne fait pas tout 😉

Alors d’accord, on va laisser les équipes collaborer et concevoir de manière collective. Mais il y a quand même des contraintes fonctionnelles et métier… Et c’est là que les cas de tests d’acceptance rentrent en jeu, pour exprimer ces règles métier.

Ex : Pour une recherche, s’assurer que l’on peut rechercher par date.

Alors oui, les stories sont INVEST, 3C… mais c’est avant tout un moyen de collaborer et communiquer avec :

• les utilisateurs ou ceux qui les représentent.
• les personnes qui vont réaliser les stories.

C’est en quelque sorte le format pivot entre les besoins et le produit réalisé.