Pas de relevé des heures avec Scrum

L'estimation du temps qu'il reste à passer sur une tâche est plus importante que la mesure du temps qu'on y a passé

La pratique habituelle de gestion de projet consiste à estimer la durée de la tâche avant de la commencer, de relever les heures passées effectivement et d'analyser les écarts constatés.

Avec Scrum, on estime aussi la tâche, et on la ré-estime régulièrement (tous les jours !) pendant son déroulement. Cette ré-estimation s'appelle le reste à faire (RAF). On se préoccupe pas des heures consommées. Une erreur serait de croire que le RAF est l'estimé au départ moins le consommé. En effet on peut avoir estimé une tâche à 20 heures, avoir travaillé 2 heures dessus et se rendre compte que c'est plus facile que prévu et que 10 heures suffiront pour finir la tâche.

Lorsque je présente la position de Scrum, j'entends : à quoi servirait de faire des estimations si on ne mesure pas le temps effectivement passé ? Les estimations servent d'abord à planifier. On peut très bien avoir des estimations sans mesure du temps réellement passé. C'est exactement ce qu'on fait avec Scrum. Ce qui nous intéresse c'est le reste à faire, pas le relevé des heures. C'est avec l'évolution du reste à faire [1]que des décisions de planification peuvent être prises, par exemple ajuster l'objectif d'un sprint en ajoutant ou supprimant des tâches.

De mon point de vue[2], la mesure individuelle du temps passé présente de nombreux désavantages :

  • ça prend du temps
  • ce n'est pas fiable [3]
  • cela pousse à considérer que l'objectif d'un projet est de tenir une estimation plutôt que de produire quelque chose
  • cela ne contribue pas à développer l'esprit d'équipe, chacun essayant de se justifier en invoquant le temps qu'il annonce avoir passé. De plus, l'affichage des différences d'heures entre membres de l'équipe peut dégrader l'ambiance.
  • cela ne sert pas à grand chose. En effet, si on observe un décalage entre une estimation et les heures effectivement passées, on ne peut pas dire si c'est un problème d'estimation ou de compétence ou de définition de la tâche.

Quand une équipe applique Scrum pour la première fois, on constate que certains membres de l'équipe ont beaucoup de réticences à donner une estimation de leurs tâches. Une des raisons est la peur d'être jugé sur la qualité de leur estimation et sur leur productivité individuelle. Cette tendance -naturelle- à considérer une estimation comme un engagement diminue quand le relevé des heures consommées n'est pas mis en exergue et qu'il est substitué par le reste à faire.

Notes

[1] montré par un Burndown Chart avec Scrum

[2] et je ne suis pas le seul

[3] en général c'est une estimation faite a posteriori

Commentaires

1. Le mardi 06 février 2007, 11:40 par Sylvek

tout un programme.
D'un coté estimer le temps à passer sur une tâche est à mon sens très difficile. Difficle car vraiment pas fiable, et effectivement ce qui est important au final, ce n'est pas le temps passé sur un problème, mais plutot le temps qu'il reste avant de le résoudre.

Néanmoins, il est bon de "logger" son activité. Pour celà j'utilise un programme maison qui me permet en temps reel de suivre mon activité. L'interet que j'y trouve est surtout d'avoir une vue réelle du temps passé sur les tâches (et non pas un moyen de fliquer).
Et ainsi essayer de prévenir au mieux pour la prochaine fois, apprendre à anticiper, connaitre ses faiblesses,répondre trop facilement au demandes exterieures (tout le monde n'a pas un Scrum Master)...

Néanmoins, comment faire quand on nous demande un délais pour une tâche avant même d'en connaitre l'étendu? c'est une question que je me pose régulièrement quand on me demande une estimation. Souvent on se retrouve à prendre un délai optimiste qu'on multiplie par 3 ou 4 suivant les humeurs.. et à part sur un coup de chance elle est fausse. Malheureusement, reajuster une tâche en court de route est très difficile lorsqu'on utilise une méthodologie classique de gestion de projet.

2. Le mardi 06 février 2007, 11:50 par Camille Bloch

Le but de Scrum n'est pas de faire un suivi d'activité, mais un suivi d'avancement (pour simplifier... je sais, je simplifie énormement...)

Même si j'aurais apprécié de pouvoir utiliser IceScrum pour faire mon suivi d'activité, il est tout a fait naturelle que ca ne soit pas inclu, car c'est complètement hors scope et nous garderons donc notre "quincaillerie" existante pour cet aspect.

3. Le mardi 06 février 2007, 21:07 par Freddy Mallet

Hello Claude, tu ne fais pas mention ici du fait que le RAF est en fait plus une mesure de l'effort nécessaire pour la réalisation de la tâche qu'une mesure du temps nécessaire. C'est d'ailleurs pour cela que certaines équipes évaluent cet effort en nombre de points et non plus en temps. Je suis sûr que cela aurait rendu ton post moins pédagogique donc c'est certainement une volonté de ta part ;-).

4. Le mardi 06 février 2007, 23:39 par Oaz

Je crois qu'il faut nettement séparer les 2 niveaux : l'estimation en points des exigences et l'estimation plus fine des taches.
La mesure réelle, a posteriori, de l'estimation fine des tâches est une perte de temps car elle peut très vite tomber dans des travers de "micro-management" (pour ne pas dire flicage) et elle n'est finalement pas si utile que ça pour savoir dans combien de temps on va arriver au bout de la tâche en question.

L'estimation en points des exigences, au contraire, me parait être un bon candidat au feedback.
Prochainement je compte suggérer la pratique suivante (au moins pour un essai). Lors de la réunion de retrospective, on regarde l'ensemble des exigences prévues pour le sprint avec leurs cotations respectives et l'équipe détermine les estimations qui, a posteriori, semblent totalement décalées par rapport à la réalité.
Un tel debriefing collectif (réalisé dans la logique des estimations relatives et non pas en temps absolu) me parait être de nature à soulever les points faibles qui sont à améliorer pour les estimations futures.

5. Le jeudi 08 février 2007, 07:26 par claude aubry

Oaz, tant qu'à faire ce debriefing sur la qualité des estimations, autant le coupler avec une ré-estimation des exigences qui restent dans le backlog(et une première estimation de celles qui ont été ajoutées pendant le sprint), ce sera plus concret.