Burnup en stories et stories finies

[Kagilum]

Bonjour,

Pendant le sprint en cours il est possible, à tout moment, de “déclarer finie” les stories du sprint. Lorsqu’une story est déclarée “finie” pendant le sprint, le burnup en stories est automatiquement mis à jour.

Dans IceScrum, faut-il déclarer une story “finie” dès que toutes ses tâches sont terminées afin de mettre à jour le burnup de stories et ainsi obtenir un indicateur sur le nombre de stories terminées (du point de vue de l’équipe). Dans ce cas il faudra modifier le statut des stories déclarées “finies” par l’équipe mais rejetées par le PO pendant la revue de sprint.
Faut-il plutôt déclarer comme “finies” les stories validées par le PO lors la revue de sprint et donc se passer du burnup de stories pendant le sprint courant ?

[Nicolas Noullet]

Bonjour,

Il est très important qu’il y ait une seule définition de “terminé” ou “fini” pour les stories et que celle-ci soit partagée par l’équipe et le Product Owner. C’est un repère fondamental du projet qui assure la confiance entre le Product Owner et l’équipe.

Dans iceScrum, la définition de fini peut être saisie depuis le dashboard ou le sprint, afin que tout le monde l’ait à disposition. Ces critères ne sont pas propres à une story en particulier : ils doivent être remplis par toute story afin qu’elle soit considérée finie. Les données propres à chaque story se trouveront quant à elles définies dans les tâches et les tests/critères d’acceptation.

Voici un example de définition de fini :

– Toutes les tâches sont terminées
– Tous les tests d’acceptation sont passés
– Le code produit est de bonne qualité
– Le code produit est couvert par des tests automatisés
– Les tests automatisés passent
– Le code produit est en gestion de configuration
– La user story est documentée
– La user story est disponible sur le serveur de pré-prod
– La user story a été essayée par le Product Owner
– La user story a été validée par le Product Owner
– La user story fonctionne dans tous les navigateurs (par ex. pour une appli web)
– Toutes les interactions utilisateur de la user story ont un temps de réponse inférieur à 2s
– etc.

C’est une très bonne chose d’essayer de terminer les stories en cours de sprint : cela signifie que l’équipe ne disperse pas son travail et ça lisse l’avancée du sprint, sprint qui ne doit surtout pas être une mini-waterfall.

Ceci dit, étant donnée la définition de fini que j’ai donnée en exemple, on voit bien que pour qu’une story soit finie en cours de sprint il faut qu’elle soit validée à la fois du point de vue technique et métier. Une telle validation nécessite la mise en place de pratiques d’ingénierie : intégration continue, déploiement en continu, etc. afin que l’équipe s’assure de la qualité technique de la story et que le Product Owner puisse l’essayer et la valider au plus tôt.

Un avantage très significatif de cette validation en cours de sprint c’est que si une story est invalidée, alors l’équipe peut rectifier le tir en cours de route s’assurer qu’elle soit finie à la fin du sprint. Si les stories ne sont validées que pendant la revue alors les stories non finies seront nécessairement repoussées au sprint suivant, ce qui réduira d’autant le travail qui pourra être fourni sur d’autres stories.

Enfin, je dirais qu’il ne faut pas essayer de faire de beaux indicateurs (certains travestissent même la réalité dans ce but…). Les indicateurs sont là pour révéler la réalité des données du projet. Le point fondamental est que ces données soient interprétées, que leur cause soit comprise / mise en perspective et que cette interprétation suscite des actions d’amélioration si et seulement si c’est pertinent.

[Kagilum]

Merci pour cette réponse Nicolas, en fait tout dépend de la définition du “fini”.

[Author]

Posts