Estimations, Vélocité & Planification

Dans une démarche agile, l’objectif des estimations n’est pas de produire des prédictions financières dures au jour près, mais de susciter la discussion au sein de l’équipe pour bien comprendre ce qui doit être réalisé.

Les estimations doivent être effectuées collectivement par ceux qui réalisent le travail (les membres de l’équipe de développement). Le Product Owner présente le besoin et répond aux questions, mais il n’impose jamais d’estimations.

1. Pourquoi Estimer en Points d’Effort plutôt qu’en Jours-Homme ?

En développement logiciel ou dans des projets complexes, l’estimation en jours-homme souffre d’un biais majeur : elle dépend fortement de la personne qui réalisera la tâche.

Un exemple concret :

Une nouvelle fonctionnalité est estimée à 2 jours par un développeur sénior, à 4 jours par un développeur intermédiaire, et à 10 jours par un nouvel arrivant. Si l’équipe s’aligne artificiellement sur le sachant, les délais risquent de ne jamais être tenus.

Les Avantages du Point d’Effort

Le point d’effort est une mesure abstraite et relative. L’effort représente la combinaison de trois facteurs :

  1. La complexité de réalisation.
  2. La quantité de travail requise.
  3. Le degré d’incertitude ou de risque.

En utilisant des User Stories de référence (par exemple : une story simple qui vaut 1 point, une story moyenne à 3 points, etc.), tous les membres de l’équipe s’accordent sur un nombre de points identique, quel que soit l’intervenant final.

Les Échelles d’Estimation

  • La Suite de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21…) : Plus l’élément estimé est volumineux, plus l’incertitude grandit. La progression non linéaire reflète cette indétermination.
  • Les Tailles de Tee-Shirt (XS, S, M, L, XL) : Très utiles en phase d’exploration pour faire des estimations à haut niveau sans se bloquer sur des chiffres.

2. Les Ateliers d’Estimation Collective

Le Planning Poker

Le Planning Poker est un format d’atelier ludique conçu pour éviter le biais d’ancrage (où la première personne qui parle influence le reste du groupe).

Déroulé d’une Session

  1. Le Product Owner présente une User Story.
  2. L’équipe pose des questions d’éclaircissement et discute de la solution technique.
  3. Chaque développeur choisit silencieusement une carte dans son jeu (suite de Fibonacci).
  4. Tout le monde abat sa carte en même temps.
  5. Si les estimations convergent, la valeur est validée. En cas d’écart fort (ex: un 2 et un 13), les votants extrêmes s’expliquent, puis l’équipe revote.

L’Extreme Quotation (Planning sous Stéroïdes)

Lorsque l’équipe doit estimer très rapidement un backlog volumineux (plusieurs dizaines ou centaines de tâches), le Planning Poker devient trop lent.

L’Extreme Quotation consiste à positionner les cartes silencieusement et en parallèle sur une grande échelle visuelle murale. En moins de 45 minutes, un backlog complet peut être ordonné et estimé de façon homogène.

3. Capacité, Vélocité et Débit

La Vélocité

La vélocité représente le nombre total de points d’effort réalisés et validés (répondant à la Definition of Done) par une équipe au cours d’une itération/sprint.

  • La vélocité se calcule de manière empirique sur la moyenne des derniers Sprints.
  • Elle permet d’anticiper la capacité d’engagement pour les prochains Sprints.

Vélocité vs Débit (Throughput)

  • Vélocité : Mesure de points d’effort (ex: 30 points livrés).
  • Débit : Nombre brut d’éléments livrés (ex: 12 User Stories terminées).

L’importance du découpage fin :

Attention à l’illusion d’équivalence ! Une User Story estimée à 8 points comporte beaucoup plus d’incertitude que deux Stories de 3 et 5 points. Plus les cartes sont découpées de manière fine et homogène, plus le débit est stable et la prévisibilité élevée.

4. Planification de Sprint & Gestion des Imprévus

Pour garantir un engagement tenable, l’équipe doit savoir anticiper les perturbations extérieures.

┌────────────────────────────────────────────────────────────────────────┐
│                        CAPACITÉ GLOBALE DU SPRINT                       │
├───────────────────────────────┬──────────────────────┬─────────────────┤
│  Périmètre Engagé (PO)        │  Bande Passante Prod │  Marge d'Imprévu│
│  (Sprint Backlog)             │  (Ex: 10 à 20%)      │  & Recette      │
└───────────────────────────────┴──────────────────────┴─────────────────┘

Comment Absorber les Imprévus pendant le Sprint ?

  • Les Bugs de Recette : Plus l’équipe travaille en flux tiré avec des Stories découpées finement, plus les bugs de recette sont étalés et corrigés au fil de l’eau.
  • Les Bugs de Production : Par nature imprévisibles, ils doivent être anticipés en réservant systématiquement une bande passante fixe (ex: 15% de la capacité globale) basée sur les historiques.
  • Les Demandes Urgentes du Management : Le Scrum Master protège l’équipe. Toute nouvelle demande doit passer par le PO, qui évalue avec l’équipe ce qui peut être retiré du Sprint Backlog en échange.
  • Un Travail Plus Important que Prévu : Pour minimiser ce risque, l’équipe s’appuie sur une Definition of Ready (DoR) rigoureuse et des ateliers 3 Amigos en amont du Sprint.

5. Ressources et Liens Utiles

  • Outil de Tirage au Sort (Rouette Tirokdo) : Utile pour désigner le facilitateur ou l’ordre de parole pendant les cérémonies.
  • Guides et Déroulés d’Ateliers : Articles méthodologiques pour animer vos sessions d’Extreme Quotation.
Retour en haut