Ma bonne pratique agile #1

Je travaille sur un projet où l’agilité tient une bonne place. Dans le cadre de l’amélioration continue, l’équipe a mis en place plusieurs pratiques avec plus ou moins de succès.

Débute donc avec cet article, le partage de notre expérience projet et de nos pratiques les plus intéressantes.

Allergiques à l’agilité, s’il vous plait ne partez pas. Ces bonnes pratiques ne sont pas réservées à l’agilité, bien au contraire. Elles peuvent s’appliquer à tout projet.

Le chiffrage à 3 points

Le contexte

Dans tout projet, une équipe fait des estimations. Dans notre cas, nous le faisons lors du planning poker en démarrage de sprint (encore appelé sprint planning, sprint poker, etc.). Nous estimons alors les user stories du prochain sprint et les tâches qui les composent. Sur notre projet, les user stories sont estimées en points de complexité et les tâches en heures.

Pour chaque tâche, l’équipe décrit les travaux à effecteur et passe à la phase d’estimation. Chaque équipier évalue alors le nombre d’heure à passer sur la tâche.

Évidemment les estimations de chaque membre sont différentes. Certains diront que l’idéal est de rediscuter puis d’obtenir un consensus. L’équipe finirait ainsi par être d’accord sur LA bonne estimation.

LA bonne estimation existe-t-elle ?

J’ai le sentiment que ces différences d’estimation sont importantes et qu’il n’est pas toujours souhaitable de les gommer. Effectivement une équipe n’est pas (ou très rarement) homogène :

  • Des compétences et des niveaux techniques différents
  • Des manières de réaliser différentes
  • Des visions plus ou moins réalistes des risques
  • Des personnes plus ou moins influentes dans l’équipe

Ces écarts dans les estimations représentent donc la sensibilité de chaque membre de l’équipe. Pour ces raisons nous avons fait le choix d’une estimation plus représentative des avis de chacun en utilisant : la méthode 3 points.

Comment ça marche ?

Pour chacune des tâches nous conservons 3 estimations :

  • a = la plus optimiste
  • m = une estimation « moyenne »
  • b = la plus pessimiste

Pour notre projet, L’estimation finale est calculée de la manière suivante :  E= (a + 4m + b) / 6

Un projet risqué pourrait donner une place plus importante l’estimation pessimiste : E = (a + m + 4b)/6

Un autre projet ambitieux pourrait l’utiliser encore différemment : E = (3a +2 m + b)/6

Bref chaque équipe adapte la méthode à son contexte, le calcul pouvant être adapté dans le temps.

Et tout ça pour quels résultats ?

Quelques exemples concrets :

exemple_estimations

Certaines fois la méthode 3 points ne sert pas car l’équipe tombe d’accord (Tâche 1) mais dans la majorité des cas, l’estimation finale sera légèrement différente de la moyenne. Et lorsqu’on considère ces petits ajustements sur l’ensemble des tâches, ce n’est pas rien…

Vous êtes réticent ? Dans notre cas, ça marche. Nous atteignons notre objectif à chaque sprint alors qu’auparavant nos résultats étaient assez aléatoires : Nos estimations sont donc plus fiables.

result

Et après tout c’est tellement simple à faire donc pourquoi ne pas essayer…

 

 

2 thoughts on “Ma bonne pratique agile #1”

  1. Une méthode intéressante mais AMHA elle va à l’encontre d’une des valeurs agile :
    « Les individus et leurs interactions plus que les processus et les outils. »

    Pour moi il aurait été préférable d’agir sur les points cités plutôt que de leur trouver un « palliatif ».

    Régler les problématiques d’influence fait parti du rôle du scrum master (ou équivalent). Celui-ci doit rester neutre et s’assurer que chaque membre de l’équipe soit entendu. Si vous n’en n’avez pas, faites tourner le rôle au sein de l’équipe.

    Les écarts de chiffrage sont aussi l’occasion pour l’équipe de mettre en avant des différences de points de vue ou de partager sur les risques.
    Dans le cas d’un chiffrage ou nous obtenons des estimations à 3, des estimations à 5 et des estimations à 8. En utilisant ta méthode nous arrivons à environ 5. Après discussion de l’équipe il y-a aussi de forte chance que le consensus se fasse aussi à 5 points. La différence est que dans ce cas :

    si les écarts sont liés aux risques : les risques seront connus et partagés de tous
    si les écarts sont liés aux compétences ou à une manière de réaliser : le chiffrage permettra à une personne qui le fait en 8 de faire appel à une personne qui le fait en 3 ou à la personne qui le fait en 3 de prendre le temps de partager ses connaissances avec le reste de l’équipe ou avec les personnes les moins expérimentées

    Pour conclure, je ne remet pas en cause la méthode, mais surtout n’en faite pas une solution facile et rapide qui vous permettrait d’aller plus vite dans vos poker planning en évitant des discussions qui sont, selon moi, indispensables.

  2. Merci Jérôme d’avoir lu et commenté.

    Je me permet une réponse :
    Sur la remarque d’aller à contre-sens du principe “Les individus et leurs interactions plus que les processus et les outils.” ; Je suis assez d’accord avec toi mais on peut toutefois convenir que cette méthode/processus/outil, appelons ça comme on veut, est très légère.
    Par ailleurs la mise en place de cette méthode s’inscrit dans un autre principe agile : L’auto-organisation puisque c’est l’équipe qui a mis en place cette méthode.

    Pour rebondir sur ce que tu dis dans ton commentaire, je reprends une phrase de l’article : « J’ai le sentiment que ces différences d’estimation sont importantes ». Ce n’est peut être pas très clair mais j’accorde une importance toute particulière à ces différences d’estimation. Et j’adhère complètement à ce que tu dis et à mon sens la méthode n’empêche pas le partage des risques ou la collaboration en vue de lisser les compétences.

    Je tiens également a précisé que cet article concerne notre équipe et notre projet. Il s’agit d’un retour d’expérience, d’un témoignage. Je ne me sens pas légitime pour dire que c’est LA solution. C’est simplement ce que nous avons essayé et qui a fonctionné pour nous.

    Et je vais finir en teasant un peu : Au final faut-il estimer ?
    Julien (à lire également sur ce blog) m’a informé de la tendance « noestimate » qui me semble intéressant à fouiller. L’objet d’un prochain article ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

1 × deux =