Quizz, la question 11 sur les storytests

La question était :

Une story présentée en démo fonctionne comme prévu mais on y découvre un cas de test auquel on n’avait pas pensé (les 4 autres passent). Que faire ?

Les 157 réponses se partagent de la façon suivante :

  1. Elle est considérée finie à 80% 0.64 %
  2. On modifie le code vite fait 1.27 %
  3. Elle est considérée comme finie et on ajoute une entrée dans le backlog de produit pour le cas trouvé 76.43 %
  4. Elle n’est pas considérée comme finie 21.66 %

Nous avons donc une story pour laquelle on (le Product Owner avec l'équipe) a identifié 4 storytests pendant le sprint. Il est conseillé qu'au plus tard au milieu du sprint, ils soient connus, pour éviter d'avoir des stories non finies à la fin. Dans notre exemple, la story est présentée à la revue, c'est donc que les tests ont été passés avec succès avant. Le Product Owner a considéré que cette story était finie.

La découverte d'un nouveau cas en revue fait partie du feedback, qui est accueilli favorablement. Mais de mon point de vue -comme celui de plus de 3/4 des répondants- cela ne remet pas en cause la fin de la story. On ajoutera une entrée dans le backlog pour traiter le comportement découvert en revue.

Cela met en évidence que l'ensemble cohérent des 5 storytests correspond à 2 entrées dans le backlog ; dans cet exemple, ce n'est pas voulu au départ, dans d'autres circonstances, c'est le résultat de l'application de techniques de décomposition de stories (quelques unes sont présentées page 177 de mon livre).

Commentaires

1. Le lundi 07 novembre 2011, 07:57 par dibus

Claude, avec tout mon respect, je ne partage pas ton analyse. En effet, à la fin du Sprint, on à un produit livrable ... Avec un bug connu ?? Et on se créé une dette (c'est la mode) avec une story de correction ? Je préfère largement considérer la story non terminé : l application reste sans bug et on a une vision plus juste de l état d avancement.

2. Le lundi 07 novembre 2011, 20:06 par Oaz

@dibus,

je crois que tu fais un contresens sur ce qu'est le product backlog. Ce n'est, à tout moment, que la liste priorisée des choses qui manquent au produit.
Il ne faut pas traiter les backlog items comme des spécifications. C'est d'ailleurs la raison pour laquelle je préfère le terme "backlog item" (cf le scrum guide) plutôt que le terme "story"

Que tu considères ou pas ta "story" terminée ne fera pas changer l'état réel du produit. Il n'y aura pas de bug en plus ou en moins !
Il vaut mieux que le product backlog soit la meilleure image possible de ce qui manque et il vaut donc mieux n'y laisser qu'un item qui représente le manque découvert lors de la revue.

3. Le jeudi 17 novembre 2011, 13:34 par @yannickameur

Si on parle de cas de test de validation de la story à faire dans l'itération, l'ajout et le bien venu dans la story
Mais si on considère qu'une story est Done (voir def du done de l'équipe) seulement si les cas de tests sont validés alors en ajoutant le test la story ne peux plus être Done.
Par contre les points de la story sont consommés et une nouvelle tache ou item est à ajouter à la prochaine itération.

@yannick, ton commentaire n'est pas très clair de mon point de vue. Voir la réponse de @oaz, qui justifie la réponse 3.