Product Owner, utilisez Gherkin pour écrire vos UserStories

En tant que Product Owner, la bonne compréhension des User Stories par l'ensemble des parties prenantes constitue l'un de vos enjeux majeurs. Le BDD peut vous y aider.

La User Story représente l'artefact phare du Product Owner. Rédigée, priorisée, détaillée, estimée, développée, testée, validée, elle parcourt un cycle de vie complet avant d'être mise de côté une fois l'objectif qu'elle matérialisait atteint. Le Product Owner est en charge de toute la phase de "préparation" de la User Story. Vous pouvez jeter un oeil à l'article d'Emilie-Anne pour revenir dans le détail de la naissance d'une User Story.

Afin de donner corps à votre User Story, Romain vous recommande de parler en Mock-ups. Pratique que j'ai toujours appliquée pour mes User Stories jusqu'à récemment... mais je suis depuis septembre Product Owner d'une API ! Les Mock-ups ne m'étant plus d'aucune aide, une nouvelle forme d'enrichissement des stories m'a sauvé la vie : le BDD et puis précisément le langage Gherkin.

BDD et Gherkin en quelques mots

Le BDD (Behavior Driven Development) est une méthodologie agile proposée par Dan North pour aller au delà du TDD (Test Driven Development). Cette méthodologie a pour objectif d'améliorer la compréhension et la collaboration du métier, du Product Owner, des développeurs, des testeurs et de toute autre partie prenante pertinente en les rassemblant autour d'un langage commun : le Gherkin.

Pour chaque User Story, un ensemble de scénarios (de 1 à environ 4 au maximum) décrit le comportement attendu en Gherkin :
Etant donné que 'contexte initial'
Quand 'un événement'
Alors 'un certain résultat'

Template d'une User Story

Aussi riches que les Mock-ups, ces scénarios illustrent par l'exemple ce que vous attendez de votre logiciel une fois la User Story développée. Ces sénarios sont repris par l'équipe de développement et codés avant la User Story sous forme de test. Quand le test passe, la story est done.

"Three Amigos" et rédaction des scénarios

Parmi les bonnes pratiques du BDD, les ateliers de travail "Three Amigos" peuvent être très bénéfiques. L'important n'est pas le nombre de participants mais la pluridisciplinarité des profils autour de la table. Idéalement, un représentant du métier (le Product Owner par exemple), un testeur, un développeur mais aussi un exploitant ou encore un commercial (tout dépend du contexte de votre produit) participent à cet atelier et écrivent ensemble les scénarios suite à la présentation de la story par le représentant métier.

Ces sessions permettent d'aligner la vision et de s'assurer de la bonne compréhension des items par tous. Elles permettent également de creuser les User Stories et de bien prévoir l'ensemble des comportements attendus (donc l'ensemble des critères d'acceptation). Assez coûteuses en temps, elles sont importantes en début de projet lorsque le produit commence à être développé. Avec l'habitude, l'équipe finit par naturellement parler le même langage et le Product Owner (ou le testeur) peut écrire les scénarios seul.

Pour aller plus loin  : Télécharger notre livre sur l'Agile Product Management