Estimation agile : guide complet
L'estimation agile est souvent mal comprise. Certaines équipes la sur-ingénièrent avec des tableaux complexes, d'autres la rejettent comme inexacte. Ce guide explique les principes, les outils et les erreurs courantes.
Pourquoi estimer ?
L'estimation ne sert pas à prédire l'avenir. Elle sert à révéler ce que l'équipe ne sait pas encore. Une bonne session d'estimation fait apparaître la complexité cachée, les hypothèses implicites et les dépendances non résolues, avant d'écrire la moindre ligne de code.
Le chiffre produit est moins précieux que la conversation qui l'a généré.
Story points vs. heures : la différence clé
Les heures mesurent le temps, qui varie selon le développeur, le jour et le contexte. Un senior finit une tâche en 2 heures ; un junior en 8. Ni l'un ni l'autre n'a tort ; ils mesurent simplement des choses différentes.
Les story points mesurent l'effort relatif dans l'expérience partagée de l'équipe. L'effort combine trois choses : le volume de travail, l'incertitude et la complexité. La complexité seule n'y suffit pas - une tâche simple mais très volumineuse peut peser plus lourd qu'une petite tâche délicate. L'échelle reste relative : un 5 est nettement plus gros qu'un 3, sans prétendre à un rapport exact. Cette abstraction rend la vélocité stable et comparable d'un sprint à l'autre.
Comment fonctionne la vélocité
La vélocité est le nombre de story points qu'une équipe complète par sprint en moyenne. Elle se calcule en fin de sprint en additionnant les points des stories terminées (pas commencées, pas à moitié faites, uniquement done-done).
Après 3 à 5 sprints, la vélocité se stabilise. On peut ensuite l'utiliser pour :
- Prévoir en combien de sprints une release sera livrée.
- Définir une prévision de sprint soutenable.
- Détecter les changements de capacité (nouveau membre, congés, astreintes).
Les erreurs d'estimation les plus courantes
| Erreur | Pourquoi ça nuit | Correction |
|---|---|---|
| Estimer en heures | Ancre sur la vitesse individuelle, pas la complexité | Passer aux story points relatifs |
| S'ancrer sur le premier vote révélé | Tue l'estimation indépendante | Révéler toujours simultanément |
| Forcer le consensus sur les outliers | Supprime des signaux de risque valides | Demander aux outliers d'expliquer, puis revoter |
| Ignorer les bugs dans l'estimation | Gonfle la vélocité, trompe la planification | Estimer les bugs qui demandent un effort réel |
| Comparer les vélocités entre équipes | Échelles et contextes différents | La vélocité est un outil interne uniquement |
Questions fréquentes
Quelle est la différence entre story points et heures ?
Les story points mesurent l'effort relatif, pas le temps. L'effort combine le volume de travail, l'incertitude et la complexité : une tâche simple mais très volumineuse peut peser plus lourd qu'une petite tâche délicate. Les heures varient selon le développeur ; l'effort relatif est propre à l'équipe et stable.
Qu'est-ce que la vélocité en agile ?
La vélocité est le nombre de story points complétés par sprint en moyenne. Après 3 à 5 sprints, elle se stabilise et devient un outil fiable pour la planification de release et la prévision de sprint.
Faut-il estimer les bugs et la dette technique ?
Oui. Si un bug demande un effort significatif, estimez-le. Si du travail de dette technique est planifié dans un sprint, estimez-le et comptez-le dans la vélocité. L'ignorer produit une vélocité gonflée qui trompe la planification.
Combien de sprints faut-il pour que la vélocité se stabilise ?
En général 3 à 5 sprints. Le premier sprint est souvent plus bas, car l'équipe calibre son estimation. À partir du 4e ou 5e sprint, la moyenne est suffisamment fiable pour prévoir les dates de release.