Ne plus mesurer les tâches d'un sprint en heures

Une alternative aux estimations en heures.

Dans un billet précédent, je notais que la ré-actualisation en heures du reste à faire pendant un sprint était difficile à obtenir des équipes. Suite à la lecture de When is Scrum not Scrum?[1], j'ai décidé d'essayer la technique proposée pour le suivi du sprint. Je la résume ci-dessous, en mettant en évidence les différences avec la pratique Scrum standard.

Lors de la réunion de planification du sprint, les tâches sont identifiées. On n'estime pas les heures à y passer. En revanche, le découpage doit être suffisamment fin pour qu'une tâche puisse être finie en une journée de travail.

Lors des scrums quotidiens, plutôt que d'actualiser le reste à faire en heures, on note simplement les tâches qui sont finies. Si une tâche n'est pas finie, c'est le signe d'un problème[2].

Le burndown chart montre normalement l'évolution du reste à faire pendant le sprint. Plutôt que de le baser sur les heures, on va simplement noter les tâches restant à faire, c'est à dire celles qui ne sont pas finies. Exemple : il y avait 49 tâches identifiées au début du sprint. Le premier jour 3 sont finies, le deuxième 5... cela donne un burndown chart avec 49, 46, 41.

Cette pratique simplifiée me paraît adaptée aux équipes peu expérimentées dans les estimations. De plus la mesure binaire[3]est de nature à motiver davantage à finir une tâche.

J'ai 2 équipes qui essaient ça, on fera le bilan dans 2 semaines.

Notes

[1] billet très intéressant sur lequel je reviendrai

[2] et c'est au ScrumMaster de faire en sorte que le problème soit résolu

[3] cela revient à considérer qu'une tâche a 2 états : pas finie et finie

Commentaires

1. Le dimanche 25 février 2007, 10:28 par Avangel

J'aime beaucoup cette façon de voir le reste à faire d'un sprint. Déjà parce-qu'il est effectivement difficile d'estimer en heures, même des tâches élémentaires. D'autre part, j'ai personnellement tendance à préférer terminer une tâche avant d'arrêter ma session de travail. Dans cette optique, c'est plus facile et motivant de se dire qu'on a une tâche à faire dans la journée, plutôt qu'un nombre d'heures à passer sur une tâche (même sans se prendre particulièrement la tête avec les heures estimées , je pense que ça un impact sur le mental).

2. Le lundi 26 février 2007, 10:14 par Matthieu

En termes de suivi du reste à faire, le principe d'avoir des tâches avec un état binaire ne me choque pas : c'est un peu ce qu'on fait lors d'une phase de debugage.
Il y a une liste de taches (les bugs), on les traite en général sans faire d'estimation préalable, et on suit le nombre de bugs restants.
Si on veut suivre ça de manière un peu moins basique, on commence en général par s'intéresser à la gravité (mineur, majeur, bloquant) plutôt qu'a la charge de travail.
Il faut dire qu'une correction de bug est en général une tâche difficile à estimer : quand on commence à avoir une idée précise de ce qu'il faut faire... hé bien la plupart du temps c'est déjà presque terminé !

Par contre en termes de planification du sprint cette méthode me laisse perplexe... Pour reprendre l'exemple, on a donc 49 tâches dont on sait simplement qu'elles tiennent chacune en 1 journée maxi.
A part si quelque chose m'a échappé, ça veut dire que chaque tâche peut durer entre 1h (voire peut-être moins) et 8h.
Donc nos 49 tâches représentent entre 49h, soit 6j et 49j de travail...
Comment savoir à partir d'une information aussi imprécise ce qui va pouvoir être fait dans le sprint ?

Mon avis est que lors de la réunion de planification du sprint une estimation en heures est implicitement faite, ne serait-ce que pour s'assurer que chaque tâche est faisable en moins d'une journée.
Dès lors que cette estimation est faite, autant la noter pour pouvoir planifier plus précisément
Par contre en termes de suivi du reste à faire, c'est vrai que si les tâches sont courtes on peut se contenter d'informations binaires (fini/pas fini) et ne pas demander d'estimations en heures, même si là aussi c'est à mon avis implicite : même s'il n'annonce que "pas fini" lors du daily scrum meeting, quelqu'un qui pense avoir bouclé sa tâche courante en une demi-heure va sans doute aussi annoncer qu'il pense finir la tâche suivante dans la journée...

3. Le lundi 26 février 2007, 12:09 par Stéphane Boisson

N'y a t'il pas aussi alors plus de risques de glisser dans des horaires "élastiques", et d'avoir donc une equipe qui s'épuise et se démotive à force de travailler trop?

4. Le lundi 26 février 2007, 18:45 par claude aubry
Comment savoir à partir d'une information aussi imprécise ce qui va pouvoir être fait dans le sprint ?

Le périmètre d'un sprint c'est le sous-ensemble du backlog de produit sélectionné. C'est à partir de ces éléments qu'on sait ce qui pourra être fait pendant le sprint. C'est seulement après qu'on déduit la liste de tâches.

5. Le mardi 27 février 2007, 10:37 par Matthieu

Vous voulez dire que le contenu du sprint est déterminé avant de faire le découpage en tâches ?
C'est très pifométrique non ?

Ceci dit, comme le découpage en tâches intervient juste après dans la même réunion, je suppose qu'il est possible de réajuster le contenu du sprint si une fois qu'on a cette vision plus précise on se rend compte qu'on l'a manifestement trop ou pas assez chargé

6. Le mardi 27 février 2007, 14:09 par Camille Bloch

le contenu d'un sprint est déterminé en fonction de la vélocité. Quand on connait la vélocité d'une équipe, on sait combien de point on peut faire.

Si on a mal estimé le poids d'un item, il sera reporté sur le sprint suivant.

Bien entendu, cela implique de connaitre la vélocité de l'équipe et de bien estimer le poids de chaque item... Et il faut quelque temps pour bien affiner tout ca, mais ensuite, ce n'est plus pifométrique comme approche.

7. Le mardi 27 février 2007, 16:08 par Matthieu

Au début j'étais parti dans cette logique, mais dans la discussion que nous avons eu autour du billet du 03/02/2007 (je tente un lien : www.aubryconseil.com/dotc... Claude ne semble pas de cet avis

Ou alors c'est juste sur le "qui remplit le sprint" que j'étais à côté de la plaque, et pas sur la manière d'estimer ce qu'on peut mettre dedans.
Il n'empêche que cette façon de faire ne fonctionne pas sur les premiers sprints, puisqu'on ne connait pas la vélocité...

Par contre c'est vrai qu'une fois le projet en vitesse de croisière (et à condition d'avoir des mesures de vélocité utilisables), ça doit permettre de planifier assez facilement les releases, ce qui donne de l'agilité pour s'adapter aux modifications du backlog de produit

8. Le mardi 27 février 2007, 16:46 par Camille Bloch

en effet, lors des premiers sprint, c'est difficle à faire. Le plus difficile, c'est d'être d'accord sur l'estimation en point.

Dans notre équipe, nous avons adopté comme point une journée idéal, soit 8 heure de travail effectif. Cela n'est pas très "Scrum" comme approche, mais déjà que cette vision a eu du mal à être adopté, baser les points sur des taille de vetement (par exemple) aurait été encore plus dure.

Du coup, nous avons pu "estimer" une vélocité, grace à ces points. En effet, nous sommes parti d'une estimation de l'efficacité des membres de l'équipe à 50% sur des taches prédéterminées (les 50% restant étant pour les pauses, les discussions non liées aux taches à faire, les assistances aux utilisateurs, etc...).

Ainsi, nous arrivon à un demi point par membre de l'équipe. Soit 10 points en 2 semaines pour une équipe de 2 (nous commencons petit...).

Pour le premier sprint (nous en avons fini un seul à l'heure actuelle) nous ne nous sommes pas trop trompé.

Le nouveau sprint introduit une nouvelle personne, nous verrons si la vélocité reste correctement estimé.

9. Le mardi 13 mars 2007, 10:36 par Didier BRETIN

Bonjour,

Camille Bloch a écrit:

"Bien entendu, cela implique de connaitre la vélocité de l'équipe et de bien estimer le poids de chaque item... Et il faut quelque temps pour bien affiner tout ca, mais ensuite, ce n'est plus pifométrique comme approche."

Je rebondis sur ce commentaire pour poser une question plus large. Je suis ce qui se fait autour des méthodes agiles, sans avoir encore sauté le pas. Une des questions que je me pose c'est comment apprécier les capacités de développement de mon équipe et comment quantifier cela avec des chiffres ? Existe-t-il une méthode pour aider à mesurer cette vélocité ?

Cordialement.

10. Le mardi 13 mars 2007, 15:02 par Camille Bloch

D'après ma maigre expérience sur le sujet (on scrum depui 3 sprints de 2 semaines...), dans un premier lieu, il ne s'agit plus "d'apprécier les capacités de son équipe", mais bien de discuter au sein de l'équipe de cette même capacité.

Autrement, il n'existe pas de méthode "miracle" pour mesurer la vélocité. A ma connaissance, seul le temps peut y arriver.

Dans notre équipe, nous avons opté pour une unité du point "assimilable" par tous les membres, la journée dite "idéale", c'est à dire que 1 point = 8h de travail réel (sans compter toutes les intéruptions, discussions, réunion et autres pauses café...).

Il a ainsi été plus facile pour l'équipe dévaluer dans un premier temps les items du backlog en nombre de points.

Ensuite, nous avons pu "estimer" une vélocité, en partant d'un coefficient de 50% d'efficacité (c'était notre estimation qui a été plus ou moins coroborée par des statistiques prises sur le net qui place ce coéfficient entre 50 et 60%). Nous avons donc un demi point réalisé par personne dans l'équipe.

Bien entendu ce coéfficient est proche de la réalité car on est sur une periode de 10 jours de travail qui permet de compenser les écarts réels.

Maintennat, nous nous rendons compte que notre référenciel nous apporte bien d'autres problèmes et nous songeons à en changer, mais pour prendre quoi? Nous ne savons pas encore...

11. Le mercredi 14 mars 2007, 14:16 par Didier BRETIN

@Camille Bloch: accepteriez-vous d'en discuter par mail ? Le mien est disponible dans l'entête de ce commentaire ;).

12. Le mercredi 14 mars 2007, 14:57 par Camille Bloch

Didier, ca serait avec plaisir, mais je ne vois pas votre email, il ne doit pas être visible...

Voici le mien : cam_bloch at yahoo.fr