Les 6 principes d’écriture d’une Userstory

Vous avez peut-être pris l’habitude d’écrire vos Userstories avec la méthode INVEST.

Mais connaissez-vous ses 6 principes pour l’écriture de ses règles et de ses exemples (via l’Example Mapping)?

Une approche Gherkin dans l’écriture des exemples

Notre approche de l’écriture des exemples (ou “scenario”, ou “critère d’acceptation”) a évolué dans nos Userstories grâce à l’utilisation de Gherkin. Il y a 3 objectifs principaux que nous essayons de garder à l’esprit lors de l’écriture des exemples :

Les scénarii doivent être considérés comme de la documentation plutôt que comme des tests,

Les scénarii doivent permettre la collaboration entre entreprendre et livrer, et non de l’empêcher,

Les scénarii doivent soutenir l’évolution du produit, plutôt que de l’entraver.

Les 6 principes pour écrire des exemples

Les 6 principes suivants fonctionnent ensemble pour soutenir ces objectifs. Pour faciliter leur mémorisation, ils ont été disposés de sorte que la première lettre de chaque principe constitue un acronyme, BRIEF, qui est lui-même le sixième principe.

B comme Business language

Les terminologies utilisées dans votre Userstory doivent provenir de votre Métier et être comprises par toute l’équipe, y compris votre Métier, sans ambiguïté.

Vous entendrez parler aussi de Ubiquitous language

R comme Real data

Indiquer des données réelles pour permettre de comprendre et de clarifier l’exemple.

Exemple de règle : Un montant à débiter doit être inférieur ou égal au seuil de 500 euros

Etant donné que (Given) Le client renseigne un montant à débiter avec une limite de 500 euros

Quand (When) son montant est de 501 euros

Alors (Then) Un message informatif lui indique qu’il dépasse le seuil de 500 euros

I comme Intention revealing

Ne négligeons pas le titre de la règle qui doit expliquer succinctement, mais clairement l’intention. C’est un aspect essentiel à une bonne documentation vivante et lue.

Les exemples doivent révéler l’intention de ce que les acteurs de l’exemple tentent d’accomplir, plutôt que de décrire les mécanismes de la manière dont ils y parviendront.

Exemple : Pour expliquer le contrôle sur le seuil d’un montant, il n’est pas nécessaire d’expliquer que l’on doit passer par différentes API, ou bien de préciser que l’on doit valider son choix avec un bouton. L’essentiel est d’indiquer l’objectif fonctionnel (par exemple, privilégier “valider” plutôt que “cliquer sur le bouton valider” car l’essentiel est la validation et non le bouton)

E comme Essential

Le but d’un exemple est d’illustrer comment une règle doit se comporter. Si un exemple ne contribue pas directement à cet objectif, il doit être supprimé. De plus, tous les exemples qui n’aident pas le lecteur à comprendre le comportement attendu n’ont pas leur place dans la documentation.

F comme Focussed

Les exemples doivent se concentrer sur l’illustration d’une seule règle et non de l’ensembles des règles de la Userstory. De plus, chaque règle doit avoir au minimum un exemple pour la décrire.

1 règle = (n) exemples

BRIEF

Il faut essayer de limiter la plupart de vos scénarii à cinq lignes ou moins. Cela les rend plus faciles à lire, à comprendre et à l’assimiler.

Passons à la pratique

Reprenons l’exemple de la règle : “Un montant à débiter doit être inférieur ou égal au seuil de 500 euros”.

Lors du 3 Amigos, le Product Owner, le développeur et le testeur qui seront en charge de la réalisation de la Userstory, on créé ces exemples pour illustrer la règle.

Comme vous pourrez le constatez ci-dessous, cette équipe n’a pas fait mention d’API de contrôle du montant à débiter, alors que techniquement, c’est ce qui va être développé.

Une règle doit être indépendante de la solution technique pour fonctionner quelle que soit la solution choisie.

Règle : Montant à débiter avec un seuil de 500 euros

Titre de l’exemple : Un montant à débiter inférieur ou égal au seuil est accepté

Etant donné que (Given) Le client renseigne un montant à débiter avec une limite de 500 euros

Quand (When) son montant est de 500 euros

Alors (Then) Le montant est accepté.

Titre de l’exemple : Un montant à débiter supérieur au seuil est refusé

Etant donné que (Given) Le client renseigne un montant à débiter avec une limite de 500 euros

Quand (When) son montant est de 501 euros

Alors (Then) Un message informatif indique que le seuil de 500 euros est dépassé.

Titre de l’exemple : Problème technique survenu lors du contrôle du montant à débiter

Etant donné que (Given) Le client renseigne un montant à débiter avec une limite de 500 euros

Quand (When) le service de vérification n’est pas disponible

Alors (Then) Un message informatif indique qu’il ne peut pas effectuer temporairement de versement.

Sources de cet article

“The BDD books, Formulation” — Seb Rose et Gaspar Nagy.

Et si l’Example Mapping se rapprochait du mouvement d’une bille | by Silvere Duval | Medium