Comment mettre des points d’effort dans une équipe ?

Vous êtes plusieurs à me demander d’expliquer la mise en place des points d’effort dans une équipe. Je vais donc faire cet article pour tenter de répondre à vos questions sur le sujet.

Qu’est-ce qu’un point d’effort ?

Le point d’effort d’une user story (ou d’une tâche technique) va inclure différentes notions que les développeurs devront prendre en compte pour faire l’estimation de celle-ci :

• l’effort à faire pour développer la demande
• la difficulté (complexité) que peut comporter la demande
• les risques qu’on imagine pouvoir rencontrer lors du développement de l’US
• les éventuelles inconnues existant au moment de l’estimation
• les dépendances potentielles avec des éléments extérieurs

Il faut accepter que le point d’effort est une notion « abstraite » qui ne peut pas être comparé à un nombre de jours homme. Mais elle permet cependant de faire de la prédictibilité.

Oui, le point d’effort prend bien une notion de temps contrairement à ce que l’on peut lire parfois. Mais son estimation ne se base pas que dessus et cette notion de temps n’est pas matérialisée par 1 point d’effort = 1 jour.

Les points d’effort en vidéo sur La Minute Agile :

La suite de Fibonacci

Les équipes agiles utilisent cette suite mathématique car elle représente bien cette notion d’estimation.

La suite de Fibonacci est : 1, 2, 3, 5, 8, 13… En général, les équipes s’arrêtent à 13 mais je vois également des équipes inclure le 21.

« Plus l’estimation est haute, plus elle est imprécise. »

C’est pour cela que la suite de Fibonacci répond parfaitement à cette idée.

En agile, on considère que de différencier 12 , 13 ou 14 n’aurait que très peu d’intérêt. En effet des estimations hautes en informatique ne peuvent pas être aussi précises car il y a trop d’éléments qui pourront interférer. Ainsi, nous mettrons 13 pour représenter une estimation qui va dans cet intervalle d’estimation.

Comment l’équipe peut définir ses points d’effort ?

Il faut comprendre que chaque équipe aura son propre référentiel au niveau des points d’effort. Comparer les points d’effort entre deux équipes n’aura pas de sens.

1/ Première estimation

Lors de la première session d’estimation, on demandera à l’équipe de bien prendre en compte les différentes notions expliquées ci-dessus. Ce n’est pas simple pour les équipes la première fois si elles ne l’ont jamais fait.

Il ne faut d’ailleurs pas hésiter à mettre une petite affiche dans la pièce pour que chaque membre de l’équipe se rappelle des différents points à prendre en compte.

2/ Premier référentiel d’estimation

Lors des premières estimations, on proposera aux équipes de définir des demandes « référentes » pour que les équipes aient un premier référentiel d’estimation.

Quand les équipes auront estimer une demande à « 1 », on la mettra comme référence d’une estimation à 1. Nous ferons la même chose avec une demande à 13.

Ce référentiel sera très utile pour certaines équipes qui découvrent l’estimation agile. Dans ce cas, on hésitera pas à mettre ce référentiel dans le management visuel de l’équipe.

Pour estimer, la méthode la plus connue aujourd’hui est celle du poker planning. Voici un article qui vous explique comment cela fonctionne :

Article : Planning Poker : estimer vos user-stories

3/ L’estimation évoluera avec le temps

En effet, l’estimation évoluera avec le temps et ne sera pas la même à l’avenir. Cela n’est pas grave car en cas de nécessité de prédictibilité, on ne prendra que les 3 derniers sprints en référence.

Voici quelques raisons (les principales) qui vont faire évoluer l’estimation de l’équipe :

• l’équipe connait de mieux en mieux son environnement
• l’équipe connait de mieux en mieux le contexte
• une arrivée ou un départ changera l’estimation

Les managers ou les product owner ne doivent jamais forcer les équipes de développement à mettre tant de point d’effort. Ils auront ce qu’il faut côté prédictibilité même si le référentiel se met à évoluer avec le temps.

Exemple simple pour comprendre l’estimation

Voici un exemple que j’aime bien qui permet de bien comprendre comment fonctionne l’estimation en point d’effort.

Je présente différents types de véhicules :

J’explique à l’équipe qu’ils doivent mesurer le point d’effort pour construire ces différents véhicules. Pour cela ils doivent se rappeler des notions indispensables à prendre en compte : difficulté, effort de réalisation, incertitude, risque et dépendances.

Je leur présente alors le premier véhicule : « voiture de sport de 300 chevaux »… Je leur demande alors de mettre un point d’effort sur celle-ci entre 1 et 13. Je ne dévoile pas les prochains véhicules.

Les équipes vont alors ensemble se dire qu’il est possible de voir une trottinette voire une fusée apparaitre. Cela leur permet automatiquement d’imaginer où situer la voiture au niveau du point d’effort.

Sans même s’en rendre compte, l’équipe va en fait créer son propre référentiel.

Je recommence l’opération avec chacun des véhicules (que je n’ai pas dévoilé au paravant) au fur et à mesure.

A la fin de l’exercice, je leur propose de mettre la trotinette comme référence basse (souvent imaginée à 1) et le feri comme référence haute (souvent imaginé à 13).

L’équipe comprend ainsi qu’elle s’est créée un référentiel de points d’effort. Il faut alors leur expliquer que c’est exactement la même chose en développement.

Cas particuliers intéressants

L’estimation impossible

Dans certain cas, on ne pourra pas forcément estimer la demande. Voici quelques cas possibles :

• besoin de rechercher des solutions
• bug dont on a aucune idée du soucis réel
• analyse de données (exemple en big data)

On va alors proposer de rajouter une notion de spike qui permet de définir un temps qu’on se donne pour aller chercher à répondre à un problème ou un hypothèse ; ces demandes ne seront ainsi pas estimée.

Article : Qu’est-ce qu’un Spike dans un projet Scrum ?

Eviter de parler de complexité

Le point d’effort n’est pas seulement l’estimation de la difficulté (complexité) d’une demande. Utiliser ce terme amène souvent les équipes à avoir une vision erronée de ce qu’est un point d’effort.

Article : Parle-t-on de complexité ou de point d’effort ?

Conclusion points d’effort

J’espère que cet article aura éclairé ceux qui me demandent régulièrement d’expliquer plus concrètement comment mettre cette estimation en points d’effort au sein des équipes agiles.

N’hésitez pas à me demander des compléments en commentaires si vous n’avez pas toutes les réponses à vos questions.