Comment rédiger une User Story ?

La User Story (US) vise à décrire un besoin d’un point de vue utilisateur, il est au centre de la démarche (User centric). Il s’agit de décrire un besoin fonctionnel afin qu’il soit réalisé par l’équipe de développement. Elle doit être compréhensible, précise tout en étant concise, d’où parfois la complexité de l’exercice.

ecrire

Elle peut être écrite depuis un logiciel, sur une feuille papier, document word ou excel.  Bref le format est libre, mais la user story se décompose en plusieurs étapes clés comme on peut le voir ci-dessous.

shema US_d.Tomasi

  • Un titre

Il doit évoquer le contenu de la user story. Dans la backlog c’est le titre qui identifiera la User story. Ex : « Accès bouton Tchat – Menu bas navigation ». Après la création d’une User story sur des logiciels un numéro (référence) lui est automatiquement attribuée.

  • Une valeur métier

Cette valeur est à renseigner par exemple entre 0 et 100 ; plus elle est haute plus la fonctionnalité est prioritaire ; elle désigne l’importance de la fonctionnalité et donc l’ordre dans lequel les développements doivent débuter.

Autre méthode de priorisation de la valeur métier : MoSCoW (Must, Should, Could, Won’t). Must étant le plus important. Mais c’est plus souvent utilisé pour déterminer la priorisation des macro fonctionnalités (feactures) et non des US. La priorisation est faite avec le Product Owner et le Métier.

  • Une estimation de l’effort

Indique l’effort que l’équipe doit produire pour réaliser la user story, on peut l’indiquer en taille de Tshirt : de XS, S, M, L, XL. Elle est renseignée par le ScrumMaster.

  • Une Affectation

Désigne qui va faire les développements de la user story ; renseignée par le ScrumMaster.

  • Un Rattachement

Une User Story peut être liée directement à la racine du Sprint, mais dans la plupart des cas elle est rattachée à une sous section, appelée « Feacture » (regroupe un ensemble de fonctionnalités liées), parfois on peut les intégrer dans une « Epic » (dans la cas ou il y a plusieurs possibilités suite à une action. (User Story -> Epic -> Feacture -> Sprint)

Kanban board_D.Tomasi

  • Description : Objectif 

C’est la fameuse phrase « En tant que … , je souhaite/je veux ……, afin de …… Exemple :

  1. En tant qu’ « Utilisateur » (ici mon profil utilisateur = un client et un prospect)
  2. Je veux « accéder au bouton Tchat du site » (on décrit le besoin)
  3. Afin « de pouvoir être mis en relation avec une personne du service client » (attention à ne pas oublier cette partie de la story qui n’est souvent pas renseignée)
  • Description : (1) Règles Métier / Critères d’acceptation et (2) Cas de tests

(1) Les règles métiers ou critères d’acceptations

  • Elles sont rédigées par le PO.
  • Il s’agit de décrire avec précision les spécifications fonctionnelles répondant à l’objectif : les différentes règles métiers, textes à afficher, indiquer si il y a une mise en page spécifique … mais normalement la mise en page doit correspondre à la CSS décrite en sprint 0.
  • Attention l’US ne doit pas être trop grosse, si c’est le cas il faut la découper                 ex : Accès bouton Tchat – Menu bas navigation étape 1 et Accès bouton Tchat – Menu bas navigation étape 2

Un des buts de la méthode agile est de vite avancer sur des petits morceaux de projets, les stories doivent être claires et pas trop complexe pour éviter de perdre du temps.

Par ailleurs l’équipe a une vélocité (capacité de développement durant un sprint), on ne peut donc pas fournir des US trop grosses ni complexe, il faut respecter les efforts types (XS à XL par exemple). En fonction de ces efforts le ScrumMaster déterminera le nombre max de stories qu’il peut embarquer sur le sprint en tenant compte de la vélocité de l’équipe.

(2) Après avoir décrit les critères d’acceptation il faut rédiger les cas de tests

  • Soit par le PO soit par le responsable qualification, cela dépend des organisations
  • Pour cela il existe la méthode de BDD (Behavior Driven Development), elle permet à l’ensemble de l’équipe de vite comprendre les cas de tests autour d’un language commun le Gherkin avec différents scénarios de tests qui seront réalisées (1 à 4 max)
  1. Given that / Etant donné que (contexte initial) : ex : Given that l’Utilisateur arrive sur la home page
  2. When / Quand (un événement survient) : Quand il clique sur le bouton Tchat « Contacter un conseiller »
  3. Then (Alors décrire le résultat qui survient) : Alors la Popin « Contacter un conseiller » s’ouvre
  • Les tests doivent être faits tout d’abord en « Pair tests » ; durant la phase de développements avec les devs et le testeur.
  • Puis en phase de recette (tests unitaires et de bouts en bouts) avec le testeur.
  • Il faut aussi penser à constituer les jeux de données ; certains jeux de données peuvent être mis dans l’US pour des tests spécifiques mais l’intégralité des jeux de données n’ont pas à être stockés dans la backlog mais dans un dossier de tests.

L’étape de rédaction des règles métiers / critères d’acceptation « CA » et BDD est très importante ; le besoin doit être clairement décrit et compris par l’ensemble de équipe (dev, PO Scrummaster et testeur)

  • Statut de la carte :

Il s’agit de l’état d’avancement de la carte visible dans le backlog (via un glisser / deposer). Les états sont définis selon les organisations, Ex : CA (en cours, Fini), Rédaction BDD (En cours, Fini), INVEST (Analyse technique), Développements (En cours, Fini), Recette (Pair test, Test, Validés), Livrée (près à être livré en prod)

  • Type de carte :

Est-ce une user story fonctionnelle, ou une Technical Story ou une Defect story (Bug à corriger) … La technical story est rédigée par le ScrumMaster. Elle n’a pas la même structure que l’US. Idem pour la carte bug (crée par le testeur).

A Éviter :

  • Trop détailler l’US : cela indique qu’elle est trop grande, il faut alors la découper.
  • Perdre la notion utilisateur dans la description

Best practices

  • Définir au préalable, lors du sprint 0, les différents rôles et/ou profils utilisateurs (administrateur, utilisateur, client, persona)
  • Décrire des parcours types utilisateur : « Customer journey »
  • Joindre des documents illustratifs (schémas, visuels) pour une meilleure compréhension
  • Relire les US avec l’équipe et le PO avant de commencer les développements
  • Soigner la Mise en forme de l’US (saut de ligne, tabulation, couleurs.. ) pour une meilleure lisibilité)

Pour terminer une User story doit être « INVEST », c’est à dire répondre à ces 6 critères

invest

  • Indépendante : l’une part rapport à l’autre,
  • Négociable : dans son contenu avant que le sprint commence,
  • Valuable : doit apporter de la valeur à l’utilisateur final,
  • Estimable
  • Small : petite car plus simple à traiter, développer, tester et estimer,
  • et testable 

En savoir plus sur la méthode Scrum – Agile 

Publicités

Une réponse à “Comment rédiger une User Story ?

  1. Pingback: Zoom sur la méthode Scrum | Webandco·

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s