Les histoires d'utilisateurs doivent être finies à la fin de chaque sprint et a fortiori à la fin d'une release. Une histoire d'utilisateur est considérée comme finie quand elle a passé avec succès les tests d'acceptation qui l'accompagnent. Si le passage de ces tests n'est pas automatisé, on va les passer manuellement au moins 2 fois : à la fin du sprint dans lequel cette histoire a été développée et puis lors du dernier sprint de la release pour vérifier qu'il n'y a pas eu de régression.

Sans aller jusqu'à la rédaction d'une documentation volumineuse[1], il convient d'avoir une liste de tests, chacun attaché à son histoire.

Exemple d'histoire d'utilisateur et des 6 tests qui lui sont associés pour un outil de gestion de projets :

HU10 : En tant que participant je m'affecte aux projets auxquels je prends part 

T1 : vérifier l'affectation à un seul projet 
T2 : vérifier l'affectation à plusieurs projets
T3 : vérifier qu'il est possible de supprimer l'affectation à un projet sans tâche en cours
T4 : vérifier qu'il est impossible de faire une affectation plusieurs fois au même projet
T5 : vérifier qu'il est possible de quitter un projet même pour le manager du projet
T6 : vérifier qu'il est impossible de quitter un projet si on a une tâche en cours

C'est le rôle du directeur de produit[2] de spécifier ces tests. C'est aussi intéressant qu'il les passe[3] avec un ou plusieurs autres membres de l'équipe. Le travail en commun sur ces tests constitue la confirmation, troisième et dernier volet de l'histoire d'utilisateur.

Notes

[1] qu'on appelle généralement un cahier de recette dans un développement traditionnel

[2] qui fait partie de l'équipe

[3] toujours dans le cas où ils ne sont pas automatisés