Un format de user-story très efficace : le story A4

Une question qui revient souvent dans le monde des Product Owner et surtout ceux qui découvrent le métier ont souvent une question essentielle : comment faire une bonne user-story ? Et c’est pour ça que je vous présente ce format que je trouve très intéressant : le story A4.

Une user-story

Tous les Product Owner sauront vous dire qu’écrire une user-story c’est “En tant que [persona], je souhaite [souhait]” (un éventuel Afin de en plus) ; cependant ce format ne répond pas à l’ensemble des problématiques et ce n’est d’ailleurs pas le but.

Si vous vous voulez voir comment découper une user-story qui est une des étapes essentielles à la création de celle-ci, je vous propose d’aller voir cet article avant de continuer : voir l’article.

Dans un déroulement normal, votre Coach Agile vous proposera de faire un Definition of Done (and Ready) des user-story afin de déterminer ce que sera une user-story complète ; c’est à ce moment là d’ailleurs qu’on définira également le format de la user-story.

Voici un article sur la Définition of Done : voir l’article.

Un format efficace dans beaucoup de projet

Avant de vous parler de ce format très classique, je vous rappelle qu’il ne s’adaptera pas forcément à 100% des projets mais je pense qu’il est applicable et efficace dans une bonne majorité.

Maintenant que le message est passé, voilà ce que contiendra une story A4 :

  • Un identifiant (celui du logiciel utilisé est pas mal)
  • Un Type de story
  • En tant que [persona], je souhaite [souhait] afin de [but]
  • Règles de gestion
  • Tests d’acceptance

Voilà ce que ça donnerait sur une jolie feuille A4 si on veut matérialiser notre user story. En affichant cela sur un mur, ça permet d’avoir une vision rapide de comment écrire notre user-story :

User Story A4
User Story A4

Des logiciels comme Jira peuvent parfaitement s’adapter à ce format, il vous suffira d’avoir des droits d’administrateur. Sur Trello, il faudra plutôt utiliser le champ description et de créer des démarcations comme un enchainement de ==== entre chaque partie.

Règles de gestion ?

Pour ceux qui arrivent un peu dans le métier de chef de projet, AMOA ou Product Owner, voici ce que sont les règles de gestion.

Les règles de gestion sont les règles métiers essentielles pour le développement de cette user-story. Ces règles sont écrites en français avec comme but de mettre le minimum de phrase ; aller au plus simple permettra d’aller au plus efficace car les développeurs comprendront plus vite vos demandes.

Il ne faut pas hésiter également à utiliser des listes classiques pour faciliter la lisibilité voire des signes connus de tous. Voici un exemple ci-dessous sur un panier d’un site e-commerce :

Je rajoute un élément supplémentaire d'un produit dans mon panier.

    - si quantité > stock alors erreur "pas assez de stock disponible"
    - si quantité < stock alors on ajoute +1 à la quantité

Avouez que c’est très facile à lire comme ça et qu’on comprend directement le travail à effectuer. Si ce cas est relativement simple, l’idée est de faire au plus simple surtout pour les cas les plus complexes.

Tests d’acceptance

Cette partie est un peu plus complexe à comprendre. Nous allons créer des phrases de façon très structurée qui vont décrire des scénarios qui valident l’ensemble de la user-story.

La façon de l’écrire sera très importante car le jour où vous désirerez faire de la BDD (Behavior Driven Development), tout sera déjà préparé.

Dans le monde informatique, on a tendance à utiliser l’anglais pour écrire les scénarios car certains outils automatiques vont prendre les phrases écrites par le Product Owner pour automatiser la création de fonctions dans le code ; et les codeurs n’aiment pas les fonctions en français.

Qu’est-ce que la BDD ?

Sans aller dans le détail, la BDD (Behavior Driven Development) est une pratique Agile créée par Dan North en 2003 qui a pour but de créer des tests fonctionnels avec un langage naturel compris de tous.

Cette pratique encourage vivement le rapprochement des équipes techniques, des équipes fonctionnelles voire des équipes métiers.

Pour faire simple, la BDD a comme principes :

  • La participation des équipes non techniques au projet pour écrire nos tests fonctionnels
  • Des scénarios automatisés pour décrire des comportements afin de faire de la non régression
  • Mieux comprendre le comportement attendu pour les équipes techniques.

Comment écrire les scénarios ?

Voici un premier exemple de 2 scénarios que nous allons écrire pour notre panier de notre site e-commerce (exemple précédent) :

Scénario:
  Etant donné que je suis sur mon panier
  Et que j'ai un produit d'id "1234" en quantité "1"
  Et que le stock restant sur ce produit est de "0"
  Quand j'ajoute "1" quantité sur mon produit
  Alors mon panier affichera une erreur

Scénario:
  Etant donné que je suis sur mon panier
  Et que j'ai un produit d'id "1235" en quantité "1"
  Et que le stock restant sur ce produit est de "10"
  Quand j'ajoute "1" quantité de mon produit
  Alors mon produit aura "2" quantités

Nous avons ici les deux scénario qui répondent aux règles de gestion que nous avions écrit précédemment.

Les guillemets sont essentiels car ils permettent aux logiciels d’automatisation de tests fonctionnels d’envoyer des variables aux fonctions qui permettront de coder les tests. Sachant que les phrases sont identiques mais que seuls ces éléments changent, les outils sauront qu’il faudra appeler la même fonction.

Donc en tant que Product Owner, ne changez pas vos phrases si on fait deux scénarios identiques a l’exception d’éléments spécifiques comme par exemple la quantité car c’est ce qui permettra de capitaliser au maximum sur vos tests.

Ce fameux langage connus par des outils de tests comme Behat ou Cucumber s’appelle le Gherkin.

Plus loin dans les scénarios

Si nous venons de voir un scénario simple, il est possible de faire des scénario en mode batterie de tests en prenant plusieurs cas possibles grâce à un concept de tableau d’exemple :

  Plan du Scénario: Ajouter x quantité d'un produit
    Etant donné que je suis sur mon panier
    Et que j'ai un produit d'id "<idProduct>" en quantité "<quantity>"
    Quand j'ajoute "<add>"en quantité
    Alors mon produit aura "<quantityFinal>" quantités

    Exemples:
      | idProduct | quantity | add | quantityFinal |
      | 0         | 10       | 10  | 20            |
      | 15        | 5        | 20  | 25            |
      | 35        | 5        | 40  | 45            |

Vous en savez déjà pas mal pour pouvoir commencer à écrire vos tests en tant que Product Owner. Je pense qu’à présent tous les Product Owner qui seront passé par cette page vont à présent vous impressionner.

Conclusion

Maintenant que vous avez toutes les clés en main, je vous souhaite de réussir à écrire des user-story complètes et de qualité.

5 Replies to “Un format de user-story très efficace : le story A4”

  1. Simpliste …
    En fait il faut savoir distinguer règles de gestion et règles métiers, règles internes et règles externes, et in fine tests de validation et tests d’acceptation.
    Les premiers peuvent être nombreux, les seconds entre 5 et 10% de leur nombre total. Ainsi il faut penser aux données, leurs partitions, leurs frontières et les alternatives pour valider.
    J’ajoute que les règles peuvent avoir une grammaire un peu plus perfectionnée (mais compatible) que celle fournie par La BDD.
    Enfin les notions de situations métiers (on est dans la recette métier et non informatique) impose une spécification plus fournie !!!

    1. Comme le dit l’article, ce format ne s’adapte pas à 100% des projets mais cependant en gardant une vision agile, il s’adapte plutôt pas mal. Maintenant attention à ne pas repartir sur des aspects trop complexes dans les projets où il faut limiter les documentations exhaustives car en cas de changement, le Product Owner devra tout revoir intégralement ; je suis pas convaincu que ta vision soit très Agile dans ta façon de vouloir tout spécifier.
      Parfois, tu devras avoir recours à des phases de Discovery & Framing avant de te lancer dans ta conception (en mode Scrum par exemple) pour éviter justement à tes user-story de prendre trop de poids.
      Pour beaucoup de projet, ce que tu nommes de simpliste et en fait juste ce qu’il faut ; sortir de toutes ces spécifications en cascades est justement l’une des phases les plus difficile quand une entreprise veut passer en Agile. Maintenant il ne faut pas s’arrêter à cet article car d’autres vont également définir des choses comme les user Journey… Des milliers de projets à ce jour prouvent que le poids des specs n’étaient pas nécessaires.
      Et si une règle était incomplète et qu’il y a quelque chose à améliorer pour X raisons sur un release ? Et ba on améliore pour la prochaine release qui arrive dans quelques jours/semaines ; si c’est bloquant, tu peux aussi retirer ta release.
      C’est simpliste aux yeux de personnes très habitués aux anciennes méthodes de spécification et très efficace aux yeux des autres.

Laissez une réponse