Return to site

Bien rédiger ses User Stories

Les Bonnes Pratiques

· Coaching Pro,Scrum

Quelles sont les questions à se poser ?

Travaillant aux côtés de Product Owner, je joue souvent un rôle de "reminder" pour assurer un formalisme cohérent lors de la rédaction de ses User Stories. Dans ce cadre, j'ai repris les bonnes pratiques à garder en tête.

Tout d'abord, une User Story est une description simple et compréhensible d'une fonctionnalité. Elle a une valeur business ou valeur métier et respecte la forme expliquée ci-dessous :

La forme canonique d'une User Story

Une User Story présente une vision utilisateur autour de 3 axes : rôle, besoin et valeur métier

  • <En tant que>>Je Veux>>Afin de>.
    • <En tant que> rôle, utilisateur
    • <Je Veux> besoin, action
    • <Afin de> valeur métier
  • Pour bien découper les types d’utilisateurs d'une user story , posez-vous la question : « De qui ai-je besoin d'obtenir le feedback sur la user story ?", pour savoir si la user story résout réellement son problème.
  • Affiner le "afin de" permet de clarifier la valeur apportée par la user story, et donc d'aider à la priorisation des user stories des prochains sprint. Si vous avez des difficultés à exprimer correctement l'objectif de la user story (le "afin de"), raisonnez en négatif : "que se passe-t-il si on ne le fait pas ? Quels sont les risques?"

Cette approche de rédaction est donc guidée par 3 questions à se poser :

  • Qui a fait la demande ou qui bénéficie de la demande ? -> le rôle utilisateur
  • Quelle est la demande ? -> le besoin
  • Quelle valeur métier découle de la réalisation de ce besoin ? -> la valeur métier

<En tant que> rôle, utilisateur - Qui a fait la demande ?

<Je veux> besoin, action - Quelle est la demande ?

<Afin de> valeur métier - Quelle valeur métier découle de la réalisation de ce besoin ?

Une “User Story” ça veut bien dire “histoire utilisateur”, pas “contrainte technique”

Dans le cas de mes projets, portant sur des SI commerciaux et de gestion, il est facile de tomber dans des cas de rédaction du type "En tant que <SI partenaire>, je veux consommer les données X, Y et Z afin de vérifier la véracité de mes données avec celles du SI appelé...".

Si c'est le cas, reprenez les questions :

  • Qui a fait la demande ?
  • Quelle est la demande ?
  • Quelle valeur métier découle de la réalisation de ce besoin ?

Une bonne User Story respecte les caractéristiques réunies sous le sigle INVEST :

  • Indépendante : une User Story est indépendante vis-à-vis des autres User Stories du backlog
  • Négociable : une User Story est un support de discussion en vue d’une amélioration du besoin initial
  • Valorisable : la réalisation d’une User Story doit rendre un service à l’utilisateur. Elle n'a de sens que si elle apporte une valeur métier
  • Estimable : une User Story doit être bien définie pour être facilement estimable, quel que soit votre mode d'estimation
  • Small : une User Story doit être réalisable sur un sprint, soit suffisamment petite ou découpée de telle manière à pouvoir être déployée sur un seul sprint
  • Testable : une User Story  oit être accompagnée de critères d’acceptabilité pour faciliter sa validation 

Les tests d'acceptation ou critères d'acceptabilités

Pour appuyer l'approche de TDD ou Test Driven Developement, Gherkin est une approche d'écriture des tests d'acceptations.

Le principe de cette approche est de mettre les tests au cœur du projet.

Avant de se lancer dans les tests d'acceptation, petits rappels pour éviter des confusions entre les différents types de tests possibles :

Quels sont les différents types de tests :

  • Les tests unitaires (TU)

Il s'agit tout simplement d'un code source qui permet de vérifier un mécanisme de l'application.

  • Les tests d'intégration (TI)

Il s'agit de tests permettant d'assembler tous les modules indépendants de l'appli et de les tester.

  • Les tests système (TS)

Ils regroupent les tests de performances, de compatibilités, de sécurité, de volume...

  • Les tests d'acceptation (TA)

C'est un outil de communication fourni par le Product Owner qui permet de déterminer quand une User Story est terminée. C'est un test qui peut être écrit conjointement avec le Product Owner, l'expert métier, un ou des devs et le Scrum Master. Les test d'acceptation sont concentrés sur le QUOI plutôt que sur le COMMENT

Ils permettent de garantir la conformité entre le produit livré et les règles fonctionnelles définies dans la User Story. Ce qui revient à décrire des cas d'utilisation ou scénarios de tests de cette histoire démontrables lors des Review de fin de sprint auprès des utilisateurs par exemple.

Le langage Gherkin "GIVEN - WHEN - THEN" pour définir ses scénarios

Ce format provient du BDD (Behavior Driven Developement). Il a pour objectif d'intégrer une formalisation du développement pour obtenir automatiquement des tests fonctionnels en écrivant des scénarios de tests compréhensibles par des individus non techniques. Cette approche sert deux objectifs : documenter les fonctionnalités à développer d’une part, et permettre de l’automatisation des tests à terme d’autre part.

La définition d’un scénario de test en Gherkin se fait selon trois étapes clés : Given, When Then.

  • Given liste les conditions initiales nécessaires au test (les données en entrée souvent)
  • When décrit les actions à effectuer (ce qui doit être testé)
  • Then décrit le résultat attendu en cas de bon fonctionnement du produit (les données que l'on veut récupérer en sortie souvent)

<Etant donné> les utilisateurs suivants : Nom/Prénom, position/fonction ou une situation de départ donnée = UN CONTEXTE

<Quand ou lorsque> j'ajoute/je supprime/je modifie cette donnée : l'utilisateur effectue une ou plusieurs ACTIONS

<et que> ....

<mais>

<Alors> je dois obtenir ce résultat : on doit pouvoir constater telles conséquences ou situation d'arrivée

<Et> est utilisé de manière optionnelle pour ajouter des conditions au besoin

L'idéal est de s'appuyer sur un fichier d'injection d'un jeu de données qui sont nos valeurs de tests pour que ça reste fonctionnel et cohérent à l'échelle de l'équipe entière.

Exemple Nominal

Fonctionnalité : Authentification

Scénario : Tentative d’authentification avec un compte valide

Étant donné que je dispose d’un compte utilisateur « marie »

Quand j’accède à la page d’authentification /auth.html

Et que je saisis mon identifiant « marie » dans le champ « Login »

Et que je saisie mon mot de passe dans le champ « Password »

Et que je clique sur le bouton « Connexion » du formulaire

Alors je suis authentifié sur le site

Et je suis redirigé vers la page « Mon compte » à l’URL /mon-compte.html

 

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OK