Montrer les conditions d'acceptation sur le tableau

Une story possède des conditions d'acceptation. Ces conditions sont définies, pour la plupart, avant le sprint où la story est réalisée. Cela peut même être une exigence pour que la story soit déclarée prête et donc éligible pour le sprint qui commence.

Évidemment au moment où on la définit, la condition d'acceptation n'est pas vérifiée. Elle ne l'est pas non plus au lancement du sprint. Pour reprendre la signalisation usuelle, cette condition sera en rouge. Cela peut être visible sur le tableau du sprint.

Conditions au lancement du sprint

Quand la story est développée pendant le sprint, l'objectif des développeurs qui travaillent dessus est de faire en sorte que ces conditions d'acceptation soient vérifiées.

Pour rester sur les couleurs :

  • une story prête a des conditions d'acceptation, indiquées en rouge,
  • une story finie les a en vert.

Conditions au milieu du sprint

Il reste possible d'ajouter une condition d'acceptation alors que la story est déjà dans le sprint. Elle sera alors en rouge, jusqu'à ce que le développement qu'elle nécessite permette de la vérifier (exemple C3 de la storyC sur le schéma).

Rendre visibles les conditions d'acceptation sur le tableau permet de mieux suivre l'avancement sur les stories. Qu'en pensez-vous ?

Cela révèle aussi les stories qui n'en ont pas (c'est mal) et celles qui en ont trop : l'idéal est qu'une story n'ait qu'une seule condition d'acceptation (c'est pas ce que j'ai mis sur mon schéma, sauf à considérer que les cases à cocher peuvent aussi être utilisées pour les critères de finition, venant de la définition de fini générique).

Commentaires

1. Le samedi 18 mai 2013, 14:12 par pierreroth64

Bonjour,

Je me permets un petit retour d'expérience sur ce site incontournable (merci à l'auteur!)

Il est clair que la définition des tests d'acceptance fait partie de la story: le test est d'ailleurs souvent bien plus explicite pour les développeurs.

Nous utilisons cette différence de niveau de description de la façon suivante :

- le PO (qui est un marketeux, légèrement geek mais non technique) exprime son besoin sous forme de user story "traditionnelle", c'est à dire 'en tant que'... 'je veux pouvoir'.... 'afin de'... Il décrit ainsi de façon claire son idée première.
- l'équipe de dev définit alors des tests d'acceptance dans des termes un peu plus précis et techniques (car "le diable se cache dans les détails" !) et les explique au PO pour qu'il saisisse bien l'ensemble, s'assure de l'adéquation avec son idée et reste "maître" de ce qui sera livré.


Concrètement notre tableau de sprint comporte alors le texte de la story et ses tests associés (sur la même feuille, ils sont indissociables!). Le découpage en tâches ayant, entre autres, conduit à définir des tâches d'implémentation des tests d'acceptance, chaque test est donc visible sur un post-it. Il passsera donc de "à faire" à "en cours" à "en revue" à "fait".
La progression d'une story est donc directement visible par l'intermédiaire de l'avancement de l'ensemble de ses post-it et il ne nous est donc pas nécessaire de maintenir un état particulier sur le tableau de sprint concernant les conditions d'acceptation: elles font partie des tâches de dev.
Fin d'une story = tous les post-it dans l'état "fait".
Encore merci pour vos articles réguliers,