Estimation des tâches

S’il y a consensus pour ce qui est d’estimer les « User Story » en « Story Points » et non en jours ou heures (Cf. dernier article de Claude Aubry et les très bons livres de Mike Cohn), il semble que le chiffrage des tâches issues de la planification des User Story ouvre la porte à quelques discussions.

En résumé, et désolé pour cette simplification extrême, il y a 2 grandes façons de chiffrer les tâches:

• En Heures : Chaque tâche est estimée en nombre d’heures nécessaires pour sa réalisation
• En Unité de Jour : Chaque tâche est estimée en jour plein ou portion de jour.

La première approche (Heure) est celle qui m’a été préconisée lors de ma formation de Scrum Master et donc naturellement celle que j’ai recommandée aux équipes que j’ai formé ou coaché. Un des avantages de cette méthode est de permettre d’identifier finement les tâches qui seront à réaliser, y compris celle qui ne prennent qu’une heure, afin de n’en oublier aucune. Un autre avantage est de faciliter la gestion des personnes qui ne sont pas disponible à plein temps sur l’itération (congés partiel, évènements externes, multi projets …) ou dont le nombre d’heures disponibles est différent des autres membres de l’équipe. Nulle méthode n’est parfaite et parmi les inconvénients de celle-ci, je citerais en particulier l’augmentation de la durée du « Sprint Planning Meeting » (plus de tâches à estimer, discussion de 10 minutes de toute l’équipe sur 1 tâche d’1 heure …), tendance au micro management et éloignement du concept de « Done ».

La deuxième approche (Unité de Jour) permet d’aller plus vite lors des évaluations et correspond bien souvent à l’esprit des membres de l’équipe qui se disent : « je pense qu’il me faut 1 jour pour faire cette tâche mais comme nous estimons en heures, je vais proposer 6 heures … puisque je suis disponible 6 heures par jour ! ». Cette méthode présente des inconvénients car en fixant la taille minimale d’une tâche disons à une 1/2 journée (si le mini est 1/8 de jour … c’est des heures !), certaines tâches ne seront plus autant visibles et pourront donc potentiellement être oubliées. Mais raisonner comme cela c’est oublier que l’important est de finir une User Story, donc de satisfaire aux critères d’acceptation (concept du « Done »), et non de suivre à la lettre ce qui a été défini à un instant donné (pas de mini cycle en V lors d’une itération).

Vous aurez bien compris que mon choix va vers la deuxième méthode (Unité de Jour) qui permet de simplifier le système en réduisant la durée des meetings et qui focalise l’équipe sur l’objectif de l’itération :  Délivrer des « User Stories » terminées (Done).