Suivi des tâches par les états

La pratique usuelle de suivi des tâches dans un sprint consiste à mettre à jour quotidiennement le reste à faire et à produire un burndown chart de sprint. Une autre pratique répandue est de suivre l'avancement avec un tableau des tâches avec 3 colonnes (ou 3 lignes).

La première pratique se préoccupe de la valeur estimée en heures du temps restant pour finir la tâche. La seconde est basée sur les états de la tâches. Une tâche du sprint est dans un de ces 3 états :

  • à faire
  • en cours
  • finie

Ces 2 pratiques ne sont pas exclusives : on peut utiliser un tableau des tâches tout en estimant le reste à faire et en produisant un burndown chart[1]. Mais je pense qu'avec un bon suivi sur le tableau des tâches on peut se passer de l'estimation du reste à faire.

Pour un développeur est-il plus facile d'estimer qu'il reste 6h sur une tâche que de dire qu'elle est en cours et qu'elle sera finie demain ?

Mon expérience avec de nombreuses équipes me pousse à privilégier le suivi par les états plutôt que par les valeurs en heures. J'ai constaté que pour les membres de l'équipe c'est beaucoup plus facile à vivre. Certains sont tourmentés quand on leur demande avec insistance le reste à faire. Ce n'est pas le cas quand il s'agit simplement de donner l'état de la tâche.

En se passant du reste à faire, on évite de perdre du temps à y réfléchir. Mais peut-on assurer un bon suivi ? Cela dépend des équipes et de l'expérience du ScrumMaster. Un bon ScrumMaster va savoir déceler un problème quand une tâche reste en cours plusieurs jours sans se terminer, par exemple.

C'est un choix à faire par l'équipe, par exemple lors d'une rétrospective, pour aller encore plus loin, que dans relever les heures, c'est mal, à la chasse au gaspillage .

Notes

[1] dans IceScrum on a les 2 et l'idée de faire ce billet m'est venue en constatant que le fait de déclarer une tâche comme finie, en la faisant glisser dans la bonne colonne, ne remettait pas son reste à faire à 0

Commentaires

1. Le mardi 15 juillet 2008, 10:02 par david

+1 pour le suivi par etat

2. Le mardi 15 juillet 2008, 11:17 par Laurent Carbonnaux

Bonjour Claude.

C'est une façon très particulière de justifier un bug d'IceScrum ;-).

L'estimation du reste à faire est la base de Scrum, depuis le planning game, jusqu'à la fin du sprint.
Je suis d'accord sur le fait que les développeurs ont du mal à donner leur reste à faire, voir même une estimation, mais c'est le minimum requis pour aller vers la "responsabilité" de chaque membre de l'équipe.
Mon expérience montre que c'est difficile au début : Les gens sont encore trop habitués à une gestion de projet façon "c'est le chef qui décide", mais une fois qu'ils ont compris que le Scrum Master n'est pas là pour leur crier dessus si le reste à faire n'est pas ce qu'il attendait, mais bien une valeur vraie immuable de l'état réel du projet, ils n’ont plus peur de donner une estimation. J’insiste souvent sur le sens du terme estimation (évaluer par prédiction) : ça peut être faux, puisque c’est une estimation.

La vision par états des tâches est une très bonne idée, mais ne peut se substituer au burndown.