Author: 
Fabrice Moll

Il n’y a pas si longtemps, je discutais avec une connaissance qui a commencé depuis peu à travailler dans l’informatique.
Nous avons abordé différents sujets comme les technologies utilisées, l’environnement de travail, …
Finalement, nous nous sommes attardés sur les estimations et (comme vous pouvez vous en douter) les débordements/dépassements.
Bill me disait (nom purement fictif) qu’ils étaient régulièrement en dépassement sur leurs projets par rapport aux estimations réalisées.

Voici un résumé de cette conversation :

Bill : Sur une grosse majorité de nos projets, nous sommes régulièrement en dépassement par rapport au temps estimé.
Moi : Il peut y avoir différentes raisons qui pourraient justifier ce dépassement.  Mais comment se déroule cette phase d’estimation ?
Bill : Et bien une personne réalise l’analyse et l’estimation.  Quand tout est validé par le client nous pouvons commencer le développement.
Moi : Donc toutes les personnes intervenant sur le projet n’estiment pas le travail à réaliser ?
Bill : Non
Moi : Et quelles sont les actions prises suite à ces dépassements ?
Bill : Et bien il n’y en a pas.  C’est la faute de l’équipe de développement, nous devons respecter ce qui a été estimé par le responsable de projet

Je ne vous cache pas que cette dernière phrase m’a fait mal au cœur pour plusieurs raisons :

  1. Pas d’action prise suite aux problèmes rencontrés
  2. Une équipe pointée du doigt
  3. Une seule personne estimant le travail à réaliser et qui finalement ne participera pas à la phase de développement.

Et c’est à ce moment que je me suis souvenu des méthodes Agiles et des bons moments passés en Planning Poker.
 Alors attention, je ne vais pas vous parler d’un nouveau jeu à la mode, mais plutôt d’une technique d’estimation.
Cette technique se pratique en équipe et la clé du succès du Planning Poker réside dans sa participation.
Chaque membre de l’équipe doit participer, tout le monde sans exception ! Les timides, les introvertis, les moins expérimentés, les expérimentés, etc…
Avant de réaliser cette phase d’estimation, le Product Owner (la personne qui possède la vision globale du projet) priorise les éléments du Backlog.
Ensuite, l’équipe doit donner des estimations d’effort pour chaque élément du Backlog.  Est c’est là qu’intervient le Planning Poker.
Pour réaliser le Planning Poker, l’équipe doit avoir une liste de fonctionnalités à livrer (le Backlog) et un jeu de cartes de Planning Poker.

Dans ce jeu, les cartes portent des valeurs qui sont plus pertinentes à l’évaluation de durée de tâches. Ces valeurs sont : 0, ½, 1, 2, 3, 5, 10, 20, 50, 100 et correspondent à l’effort nécessaire pour qu’une fonctionnalité donnée soit réalisées.

Déroulement du Planning Poker

  1. Chaque membre de l’équipe possède un jeu de carte
  2. Le Product Owner lit la description de l’élément du Backlog que l’équipe doit estimer et fourni des détails supplémentaires si nécessaire
  3. Chaque membre de l’équipe choisit une carte qui correspond à son estimation et la pose face cachée sur la table pour ne pas influencer les autres.
  4. Les cartes sont retournées uniquement lorsque tout le monde a réalisé son estimation
  5. Si les estimations sont trop différentes, les membres de l’équipe ayant donné l’estimation la plus grande et la plus petite donnent les raisons de ce choix. (Cela est peut-être lié à un manque d’informations)
  6. Lorsque tout est clair, l’étape 3 peut être recommencée.

Si tout le monde propose la même estimation, c’est fini.  Mais comme je le disais au point 5, parfois la discussion est engagée et un Scrum Master (facilitateur de processus) peut faciliter la discussion.
Cette personne sera capable de savoir à quel moment il est nécessaire de, par exemple, laisser d’abord la parole à un profil junior plutôt qu’à un profil plus expérimenté, etc…
Dans certaines équipes, si un consensus n’a pu être trouvé, elles prennent l’estimation la plus grosse.
Comme je l’écrivais au début de cet article, le Planning Poker est une technique d’estimation mais il apporte surtout certains avantages comme :

  • Encourager une discussion ouverte sur les estimations
  • L’estimation de groupe plutôt qu’une estimation d’une seule et unique personne
  • L’exposition des risques et problèmes pendant la présentation des éléments du Backlog

Et pour vous ? Comment se déroule cette phase d’estimation ?

Newsletter