User stories, critères d'acceptation, estimation et backlog

Une user story (en français, récit utilisateur) décrit un besoin en une phrase, du point de vue de celui qui en profite : « En tant que rôle, je veux action afin de bénéfice ». Accompagnée de ses critères d'acceptation, elle devient un élément du Product Backlog que l'équipe peut estimer, réaliser et vérifier. Ce chapitre montre comment écrire une bonne story, la découper, l'estimer en points avec le planning poker, puis utiliser la vélocité pour remplir un sprint sans le surcharger.

Le format d'une user story

En tant que salarié emprunteur, je veux réserver un ordinateur portable pour une période afin de l'avoir le jour de mon déplacement sans écrire à la logistique.

Les trois parties ont chacune un rôle :

Une story n'est pas une spécification complète. On dit qu'elle tient en trois C : une carte (la phrase, assez courte pour tenir sur un post-it), une conversation (le détail se discute entre le Product Owner et l'équipe, au moment où l'on va la réaliser) et une confirmation (les critères d'acceptation, qui disent quand elle est terminée).

Voici les premières stories de Prêt'Matos :

Les critères d'acceptation

Les critères d'acceptation sont les conditions qu'une story doit remplir pour être acceptée par le Product Owner. Ils lèvent l'ambiguïté avant le développement et servent directement de cas de test. Pour la story 4 :

• la réservation porte sur un matériel, une date de début et une date de fin ;
• on ne peut pas réserver un matériel déjà réservé sur une partie de la période ;
• la date de début ne peut pas être dans le passé, et un prêt dure au plus 15 jours ;
• après validation, la réservation apparaît dans « mes réservations » et la logistique la voit dans son planning.

On les écrit souvent au format Étant donné / Quand / Alors (en anglais Given / When / Then), issu du développement piloté par le comportement (BDD) : le contexte de départ, l'action, puis le résultat attendu.

# language: fr
Fonctionnalité: Réserver un matériel

  Scénario: Le matériel est déjà réservé sur une partie de la période
    Étant donné que le portable PC-07 est réservé du 10 au 14 mars
    Quand Julie demande à réserver PC-07 du 12 au 18 mars
    Alors la réservation est refusée
    Et le message « PC-07 est déjà réservé du 10 au 14 mars » s'affiche

  Scénario: Le matériel est libre
    Étant donné que le portable PC-07 n'a aucune réservation en mars
    Quand Julie demande à réserver PC-07 du 12 au 18 mars
    Alors la réservation est enregistrée
    Et elle apparaît dans la liste « mes réservations » de Julie

Ce format, appelé Gherkin, peut être exécuté par des outils de tests automatisés comme Cucumber, qui reconnaissent les mots-clés français grâce à la première ligne # language: fr. Même sans outil, il oblige à penser aux cas limites : chevauchement de dates, période dans le passé, matériel en réparation.

Ne confonds pas les critères d'acceptation, propres à chaque story, et la Definition of Done, commune à toutes les stories (code relu, tests passés, déployé en recette : les artefacts). Une story est terminée quand elle remplit les deux.

La grille INVEST

Une bonne user story est INVEST :

Découper une story trop grosse

Une story trop grosse pour un sprint s'appelle une épopée (epic). « En tant que gestionnaire, je veux gérer le cycle de prêt du matériel » est une épopée : elle contient la sortie, le retour, la prolongation, les retards, les pannes. On la découpe en stories plus petites, chacune utile, selon l'un de ces axes :

Le Product Backlog de Prêt'Matos

Le Product Backlog est ordonné : le haut est détaillé et estimé, prêt à entrer dans un sprint ; le bas est plus grossier et sera précisé plus tard. Le Product Owner le réordonne en continu selon la valeur, les risques et les dépendances. Voici celui de Prêt'Matos au début du projet, avec les estimations en points et le sprint où chaque élément a finalement été terminé :

Certaines équipes ajoutent une Definition of Ready : la liste de ce qu'un élément doit avoir pour entrer dans un sprint (une story au bon format, des critères d'acceptation, une estimation, pas de dépendance bloquante). Ce n'est pas une notion du Scrum Guide, mais elle évite de commencer un sprint avec des éléments flous.

Estimer en points avec le planning poker

Les équipes agiles estiment souvent les stories en points (story points) plutôt qu'en heures. Un point n'est pas une unité de temps : c'est une mesure relative de la taille d'une story, qui mêle la quantité de travail, la complexité et l'incertitude. On choisit une story de référence (« se connecter » vaut 3) et on compare : « réserver » est plus gros, avec des règles de chevauchement, disons 5.

Pourquoi des points ? Parce que l'être humain compare beaucoup mieux qu'il ne mesure : tu sais dire qu'une story est deux fois plus grosse qu'une autre bien plus sûrement que dire qu'elle prendra 13 heures. Et les points ne dépendent pas de la personne qui fera le travail.

Le planning poker est la technique d'estimation la plus répandue :

1. Chaque membre de l'équipe a un jeu de cartes portant une suite proche de celle de Fibonacci : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, plus « ? » (je ne sais pas).
2. Le Product Owner lit la story et répond aux questions.
3. Chacun choisit une carte en secret, puis tout le monde la retourne en même temps.
4. Si les valeurs sont proches, on retient la valeur commune. Sinon, le plus bas et le plus haut expliquent leur choix : souvent, l'un a vu une difficulté ou une solution que l'autre ignorait.
5. On revote jusqu'à converger.

Les écarts de la suite grandissent avec les nombres : il ne sert à rien de débattre entre 14 et 15, l'incertitude d'une grosse story ne permet pas cette précision. Une story estimée à 20 ou plus est presque toujours une épopée à découper.

La vélocité et la capacité d'un sprint

La vélocité est le nombre de points des éléments terminés (conformes à la Definition of Done) pendant un sprint. Un élément à moitié fini compte zéro. Prêt'Matos a livré 8 points au sprint 1 (éléments 1, 2 et 3), 10 au sprint 2 (éléments 4 et 5 ; l'élément 6, non terminé, est retourné au backlog) et 12 au sprint 3 (éléments 6 à 10). Vélocité moyenne : (8 + 10 + 12) ÷ 3 = 10 points par sprint.

La vélocité sert à prévoir, pas à juger :

• pour remplir un sprint : l'équipe prend environ autant de points que sa vélocité moyenne, en tenant compte des absences prévues (avec un membre sur trois absent la moitié du sprint, on vise un sixième de moins) ;
• pour prévoir une date : après le sprint 3, il reste l'élément 11, soit 8 points ; à 10 points par sprint, un sprint suffit. Si le backlog restant faisait 45 points, il faudrait 45 ÷ 10 = 4,5, donc 5 sprints, soit 10 semaines avec des sprints de deux semaines.

Pour remplir un sprint, on prend les éléments dans l'ordre du backlog tant que le total reste dans la capacité. Si l'élément suivant ne rentre pas, on en discute avec le Product Owner : il peut accepter qu'on prenne un élément plus petit situé plus bas, ou préférer découper l'élément trop gros.

Exercices

# language: fr
Scénario: Annulation trop tardive
  Étant donné que Karim est inscrit au cours de yoga de 18 h
  Et qu'il est 16 h 30
  Quand Karim demande à annuler sa réservation
  Alors l'annulation est refusée
  Et le message « Annulation impossible moins de deux heures avant le cours » s'affiche