Un remède contre la manie d'estimer les tâches - Ne le faites pas, c'est tout
Source : A Cure for Task Estimation Obsession
Date : 29/01/2009
Traducteur : Fabrice Aimetti
Date : 06/03/2010
Traduction :
Je vois souvent des équipes obsédées lors des réunions de planification des sprints, notamment par l'estimation des tâches. J'insiste, réellement obsédées. Deux jours de planification pour un sprint de deux semaines ? Croyez-moi ou non mais cela arrive. Même s'ils se plaignent de passer trop de temps en réunions Scrum, ils vont insister pour se prendre la tête sur l'estimation de chacune des tâches. Pour les équipes qui souhaitent profiter de leur expérience acquise en Scrum et optimiser leur planification, éliminer purement et simplement l'étape d'estimation des tâches est une solution possible.
Ne soyez pas choqué. C'est possible. Un avertissement néanmoins. Pour les équipes qui débutent en Scrum, je déconseille d'éliminer tout de suite l'étape d'estimation, en tout cas pas avant d'avoir atteint une vélocité stable.
Par contre, une fois que vous avez atteint une vélocité stable, vous pouvez utiliser les concepts des story points et de vélocité pour vous épargner d'estimer les tâches lors des planifications de sprint. Le temps consacré à l'estimation des tâches peut alors être utilisé plus raisonnablement pour créer un logiciel opérationnel. Je vais vous présenter une démarche en plusieurs étapes que vous pourrez employer pour progressivement éliminer l'estimation des tâches de votre processus de planification d'un sprint.
Sommaire
Contexte
Avant de commencer, rappelons rapidement la raison d'être de la planification de sprint (nous voulons ici garantir que nous satisferons les besoins de départ lorsque nous aurons optimiser le processus. Nous planifions un sprint pour nous retrouver dans la situation suivante :
- une compréhension des objectifs du sprint, partagée par toute l'équipe
- une compréhension du travail qui va être réalisé pendant le sprint, partagée par toute l'équipe
- un environnement dans lequel chaque membre de l'équipe sait ce qu'il doit réaliser à l'étape suivante (ou en tout cas qui lui permet de le retrouver en quelques secondes)
- un réel engagement de l'équipe à livrer une certaine quantité de valeur exprimée sous la forme d'éléments du backlog produit
- et un burndown chart que l'équipe pourra utiliser pour observer sa progression durant le sprint.
L'estimation des tâches répond le plus souvent à l'objectif 5, et pour certaine équipes à l'objectif 4. Si nous pouvons atteindre ces deux objectifs sans avoir besoin d'estimer les tâches alors nous sommes libres de ne plus estimer du tout les tâches, n'est ce pas ? Si vous êtes d'accord sur ces points alors je vous présente ici la démarche à utiliser pour progressivement vous passer de l'estimation des tâches.
Étape 1 : établissez une vélocité stable
Utilisez votre processus standard de planification de sprint, qu'il prenne deux jours ou deux heures, jusqu'à ce que vous constatiez que votre vélocité est stable (il y a beaucoup de discussions sur comment atteindre une vélocité stable et c'est un sujet trop vaste pour le traiter ici ; pour en savoir plus, je vous conseille de lire "Agile Estimating and Planning" de Mike Cohn). Assurez-vous que votre équipe passe le test Nokia en produisant un logiciel potentiellement livrable à chaque sprint (autrement dit que vous avez prouvé que vous pouviez correctement calculer votre vélocité). Une fois que vous avez obtenu une vélocité stable, votre équipe pourra s'engager et réussir à atteindre les objectifs en se basant uniquement sur une vélocité avérée et une estimation des éléments du backlog produit en story points. Vous souhaitez bien dans tous les cas atteindre ces objectifs que votre niveau de mise en œuvre de Scrum soit bon ou pas, n'est-ce pas ?
Étape 2 : expérimentez avec un burndown chart basé sur les tâches
Lorsque vous pensez être prêt pour ne plus estimer les tâches, commencez à utiliser deux burdown charts au lieu d'un seul. Continuez à utiliser votre burndown actuel basé sur l'effort donc l'estimation des tâches du backlog du sprint. Utilisez un nouveau burndown chart qui sera uniquement basé sur le nombre de tâches dans le backlog sans tenir compte de leurs estimations. Ce nouveau burndown chart peut être baptisé burndown chart basé sur les tâches.
Votre classique burndown chart basé sur l'effort démarre avec le total des tâches estimées pour le sprint et, étant donné que les estimations sont révisées quotidiennement, le burndown continue à refléter la quantité estimée d'effort restant à produire lors du sprint. Cette quantité a heureusement tendance à tendre vers zéro. Votre nouveau burndown basé sur les tâches démarre quant à lui avec le nombre total de tâches identifiées pour le sprint. Les estimations ne sont pas mises à jour dans ce cas et la tâche est déclarée terminée sur le burndown (passe donc de 1 à 0). Pour de meilleurs résultats, assurez-vous que le découpage des tâches ait produit des tâches qui soient les plus petites possibles. Le burndown chart basé sur les tâches reflète le nombre total de tâches estimé et restant à réaliser dans les sprints et non l'effort estimé restant à produire. Cela fonctionne mieux si vous avez plein de petites tâches, typiquement réalisables en un jour ou même moins.
Assurez-vous que les deux burndown charts soient bien synchronisés et qu'ils vous donnent tous les deux la même visibilité de votre progression durant le sprint. Si vous pensez que le burndown basé sur les tâches n'est pas utile, passez à l'étape 3.
Étape 3 : rétrécissez les tâches pour améliorer le burndown basé sur les tâches
Un bon et instructif burndown chart dépend du nombre de petites tâches. D'un point de vue conceptuel, si vous n'avez qu'une seule tâche par éléments du backlog produit dans le backlog du sprint, vous disposez peut être d'un excellent burndown chart basé sur l'effort parce que chaque mise à jour quotidienne de l'estimation des tâches est donnée avec une granularité arbitraire (sauf que si vos éléments du backlog produit ont réellement une seule tâche chacun alors cela indique que vous avez un problème soit avec vos stories soit avec votre découpage en tâches).
Par contre, le burndown chart basé sur les tâches sera, pour ce sprint, insensible à une mise à jour quotidienne puisque les tâches auront tendance à tenir sur plusieurs jours et votre progression ne sera pas visible avant que la tâche soit terminée. La solution est de découper en petites tâches. Une bonne règle est que la tâche soit réalisable en une journée voire moins.
Étape 4 : arrêtez d'estimer les tâches
Lorsque vos deux burndown charts contiennent des informations similaires et que vous pouvez livrer en vous engageant sur des sprints basés sur la vélocité, vous pouvez arrêter d'estimer les tâches et ne plus gérer un burndown chart basé sur l'effort. Ce sera facile pour certaines équipes et pour d'autres cela prendra plusieurs sprints. L'idée clé est d'utiliser correctement la vélocité. Notez bien que vous continuerez encore à découper en tâches. Éliminer le tâches est une étape encore différente.
Qu'avons-nous finalement perdu en n'estimant plus les tâches ? L'estimation des tâches sert les objectifs 4 et 5 de la liste de départ. Nous disposons toujours d'un burndown chart pour suivre la progression donc nous servons toujours l'objectif 5. Nous n'avons plus besoin de l'objectif 4 parce que notre équipe a prouvé sa capacité à s'engager sur des estimations d'éléments du backlog produit en story points et n'utilise plus l'estimation des tâches pour validation.
La seule chose que nous avons peut être perdue est de ne plus fournir un axe de visibilité sur le planning des travaux à réaliser durant le sprint (objectif 2). Autrement dit, en ne demandant plus d'estimations, nous avons peut être supprimer une forme de pression psychologique/motivation pour traiter la problématique de planification correcte des tâches qui exigeait un travail de fond sur le sujet, en regardant les problèmes un par un, en faisant le parallèle avec des travaux similaires et plus généralement en apportant de façon active de la connaissance et de l'expérience. Était-ce vraiment primordial ? Seuls votre équipe et vous-même pouvez répondre à cette question...
