Que sont les points d'histoire ? Guide pratique

Un point d'histoire est une unité d'effort relatif attribuée à un travail par une équipe. Il combine sa complexité, son incertitude et son volume, plutôt que d'indiquer le nombre d'heures nécessaires. Les équipes comparent chaque élément aux autres (« celui-ci représente à peu près deux fois plus de travail que celui-là ») au lieu de prédire une durée précise. Les points sont le plus souvent choisis à l'aide d'une échelle comme Fibonacci pendant une séance de planning poker. Voici ce qu'ils mesurent vraiment, ce que disent les données et comment les utiliser sans trop promettre.

Qu'est-ce qu'un point d'histoire ?

Le point d'histoire répond à une question comparative, pas absolue. Au lieu de demander « combien d'heures cela va-t-il prendre ? », l'équipe demande « quelle est la taille de ce travail par rapport à ceux que nous connaissons déjà ? ». Une histoire que tout le monde juge petite peut valoir 2, une autre plus conséquente 5, et une tâche importante et floue 13. Le chiffre ne correspond à aucune durée fixe : c'est une mesure relative et partagée.

Cette unité abstraite permet de dissocier l'estimation de la vitesse de travail d'une personne et de la pression liée à un engagement sur une échéance. Un développeur débutant et un développeur expérimenté peuvent prendre un temps différent pour effectuer une tâche, tout en convenant qu'un élément représente environ deux fois le travail d'un autre.

De quoi se compose un point d'histoire ?

Trois facteurs sont réunis dans un même chiffre :

• Complexité : la difficulté du travail, le nombre de composants impliqués et le nombre de systèmes concernés.
• Incertitude : ce que l'équipe ignore encore. Les inconnues et les risques font augmenter le nombre.
• Volume : la quantité de travail répétitif, même si chaque tâche est simple.

C'est pourquoi deux éléments qui prendraient un temps similaire peuvent recevoir des nombres de points différents. Une modification simple répartie sur quarante fichiers et un algorithme complexe dans un seul fichier sont tous deux « importants », mais pour des raisons différentes.

Pourquoi les équipes estiment-elles en points plutôt qu'en heures ?

La popularité de l'estimation relative tient davantage aux personnes qu'aux mathématiques :

• Elle dissocie l'estimation de la personne. La durée en heures dépend de qui effectue le travail. La taille relative est censée être plus stable d'une personne à l'autre.
• Comparer est plus rapide que prédire. Déterminer qu'un élément est plus important qu'un autre est plus rapide que de prévoir une durée précise ; les séances avancent donc plus vite.
• Elle évite la fausse précision. « 13 points » exprime honnêtement l'incertitude. « 16,5 heures » prétend à une précision que personne ne possède.
• Elle nourrit la discussion. Le principal résultat d'une estimation en équipe n'est pas le chiffre, mais la discussion qui fait ressortir le travail caché, comme lors d'une séance de planning poker.

Ces avantages sont réels. Il est toutefois important d'être honnête sur un aspect que la plupart des guides passent sous silence.

Ce que montrent réellement les recherches

L'affirmation courante selon laquelle les points d'histoire seraient plus précis que les estimations en heures est mal étayée par les études contrôlées.

Dans une série d'expériences contrôlées, des développeurs professionnels ont estimé les mêmes tâches de deux façons : certains en points d'histoire, d'autres en heures de travail. Les estimations en points se sont révélées moins précises que celles en heures et ont pris plus de temps à produire, même pour des développeurs très expérimentés en points d'histoire. La même étude a constaté que la « taille » en points d'une tâche variait considérablement selon la personne qui l'estimait, soit l'inverse de l'indépendance à l'égard de l'estimateur que les points sont censés apporter.

Cette tendance se confirme à grande échelle. Dans une analyse publiée en 2022 de 37 440 histoires utilisateur réelles issues de 37 projets open source, les chercheurs ont comparé les points d'histoire attribués par chaque équipe à la durée réelle du travail. Les points correspondaient bien à l'effort réel dans environ 7 % seulement des projets. Dans les autres, la corrélation était moyenne ou faible ; pour près de trois histoires sur quatre, l'estimation humaine initiale était erronée, trop élevée ou trop basse. Les revues plus générales de l'estimation agile nuancent ce constat sans le contredire : les points d'histoire sont la méthode la plus courante pour évaluer la taille du travail, mais rien ne prouve solidement qu'ils prédisent l'effort avec précision. (Références complètes dans les Sources ci-dessous.)

La conclusion honnête : les points d'histoire ne permettent pas de prévoir de manière fiable la durée d'un élément isolé. Si vous les adoptez en espérant obtenir une prévision précise pour chaque élément, vous serez déçu — et les recherches l'expliquent.

À quoi servent donc les points d'histoire ?

Ils sont très utiles, à condition de les employer à bon escient.

• Créer une compréhension commune. Lorsque les votes divergent, la discussion fait apparaître des hypothèses, des tâches manquantes et des risques. Cet alignement est le véritable résultat de la séance et justifie le temps consacré.
• Établir des prévisions approximatives sur de nombreux éléments. Les estimations individuelles sont imprécises, mais sur un backlog complet, certaines erreurs se compensent. En suivant le nombre de points réalisés par l'équipe à chaque sprint (sa vélocité), on obtient une prévision approximative utile, bien meilleure que la somme d'heures devinées.
• Repérer les éléments préoccupants. Un 13 ou un 21 indique que la tâche est trop importante ou trop incertaine. Découpez-la avant qu'elle ne pose problème.
• Rendre l'estimation plus humaine. L'évaluation relative évite la pression des échéances et la culpabilisation individuelle associées aux estimations en heures.

Remarquez qu'aucun de ces usages n'exige que les points mesurent précisément l'effort. Ils nécessitent une équipe qui discute et compare les éléments de façon cohérente.

Comment estimer en points d'histoire

1. Choisissez une échelle. La plupart des équipes utilisent un jeu de cartes Fibonacci (0, 1, 2, 3, 5, 8, 13, 21). Les écarts croissants reflètent une incertitude croissante : il n'est donc pas nécessaire de départager minutieusement les grands éléments.
2. Choisissez une histoire de référence. Convenez d'un élément bien compris comme point de repère (« celui-ci vaut 3 chez nous »). Estimez les autres par comparaison.
3. Estimez ensemble et révélez les votes ensemble. Utilisez le planning poker pour éviter que le premier chiffre annoncé n'influence les autres. Retrouvez la méthode complète dans notre guide pas à pas.
4. Réestimez lorsque vous en savez davantage. Les points reflètent la compréhension actuelle, ce n'est pas un contrat. Mettez-les à jour lorsque la situation évolue.

Points d'histoire et heures

Aucune méthode n'est magique. Si une partie prenante a réellement besoin d'une date, les points seuls ne la fourniront pas. Les tendances de vélocité accompagnées d'une discussion vous rapprocheront davantage de la réalité qu'une pile d'heures devinées.

Erreurs et mauvais usages courants

• Convertir les points en heures. Un tableau « 1 point = 4 heures » annule tout l'intérêt des points et réintroduit une fausse précision.
• Comparer la vélocité de plusieurs équipes. Les points sont calibrés par équipe : le 8 de l'équipe A n'est pas celui de l'équipe B. Utiliser la vélocité pour classer la productivité est un anti-pattern bien connu.
• Faire des points un indicateur de performance. Dès qu'ils deviennent un objectif, ils sont artificiellement gonflés et perdent leur signification (la loi de Goodhart en pratique).
• S'attendre à une précision par élément. Comme le montrent les recherches, les points attribués à un élément ne prédisent que faiblement sa durée réelle. Faites des prévisions sur de nombreux éléments, pas sur un seul.
• Ne jamais réestimer. Les points attribués avant de comprendre le travail ne sont pas immuables. Actualisez-les.

Foire aux questions

Les points d'histoire sont-ils équivalents aux heures ?

Non. Les heures correspondent à une durée absolue liée à une personne précise. Les points d'histoire sont une mesure relative qui combine complexité, incertitude et volume, et qui est censée être indépendante de la personne qui effectue le travail.

À combien d'heures correspond un point d'histoire ?

Il n'existe pas de conversion fixe ; en créer une contredit l'objectif. Certaines équipes constatent après coup qu'un point correspond souvent à une certaine plage de temps, mais il s'agit d'une tendance observée, pas d'une règle d'estimation.

Quelle échelle utiliser pour les points d'histoire ?

Fibonacci (0, 1, 2, 3, 5, 8, 13, 21) est la plus courante, car ses écarts croissants reflètent l'incertitude accrue des éléments plus importants. Les tailles de tee-shirt conviennent aux évaluations rapides et approximatives.

Les points d'histoire sont-ils vraiment précis ?

Les données sont peu convaincantes pour prédire l'effort d'un élément isolé : les études contrôlées ne démontrent pas d'avantage clair par rapport aux heures, et les analyses à grande échelle montrent que la corrélation entre points et effort réel est irrégulière. Leur valeur réside dans la compréhension commune et les prévisions approximatives portant sur de nombreux éléments, pas dans la prédiction précise de chacun.

Peut-on comparer la vélocité de plusieurs équipes ?

Non. Les équipes calibrent leurs points chacune de leur côté ; leurs vélocités ne sont donc pas comparables. Utiliser la vélocité pour classer les équipes encourage à gonfler les points et constitue un anti-pattern courant.

Qui attribue les points d'histoire ?

Les personnes qui feront le travail, collectivement, généralement pendant une séance de planning poker. Le Product Owner clarifie le périmètre sans fixer le chiffre, et le Scrum Master anime la séance.

Les points d'histoire mesurent-ils l'effort ou la complexité ?

Les deux, ainsi que l'incertitude et le volume. Ils combinent plusieurs facteurs en un seul chiffre relatif. C'est pourquoi deux éléments dont l'effort brut est similaire peuvent recevoir un nombre de points différent.

Sources

1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
2. Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates? (expériences contrôlées menées auprès de développeurs professionnels).
3. Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022 (37 440 histoires utilisateur, 37 projets).
4. Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.