Les points d’histoire constituent une unité d’estimation relative : un chiffre unique qui rend compte de l’ampleur perçue d’une tâche, en combinant sa complexité, la charge de travail qu’elle représente et son degré d’incertitude. Il est essentiel de noter qu’un point d’histoire n’est pas une mesure du temps. Au lieu de se demander « combien d’heures cela va-t-il prendre ? », une équipe se demande « comment cela se compare-t-il au travail que nous avons déjà accompli ? » — et ce petit changement rend les estimations plus honnêtes et plus utiles.

Pourquoi une estimation relative, et non en heures ?

Les gens ne sont pas fiables lorsqu’il s’agit d’estimer une durée absolue, mais ils sont étonnamment doués pour les jugements relatifs : nous pouvons déterminer qu’une tâche est à peu près deux fois plus difficile qu’une autre, même si nous ne savons pas combien de temps chacune prendra. Les points de story s’appuient sur cette capacité. Ils permettent également d’éviter trois problèmes qui affectent les estimations basées sur les heures :

  • Une estimation n’est pas un engagement. Les heures incitent les parties prenantes à considérer les « 8 heures » comme une promesse ; les points permettent de considérer l’estimation comme une prévision.
  • Une même tâche prend plus ou moins de temps selon les personnes. Un point reflète le travail accompli, et non la personne.
  • La durée ne tient pas compte du risque. Une tâche courte mais incertaine peut s’avérer plus risquée qu’une tâche longue et bien maîtrisée — les points reflètent cette incertitude.

L’échelle des points d’histoire

La plupart des équipes utilisent une échelle de type Fibonacci — 1, 2, 3, 5, 8, 13, 20 — plutôt qu’une échelle Linear. Ces écarts croissants sont délibérés : plus un élément est grand, moins il est possible de le dimensionner avec précision ; l’échelle cesse donc de prétendre qu’il est possible de distinguer un 14 d’un 15. Si un élément dépasse environ 13, c’est le signe qu’il faut le diviser en éléments plus petits que l’équipe peut comprendre et livrer au cours d’un sprint.

Comment les équipes attribuent les points : le « planning poker »

La méthode d’estimation la plus courante est le planning poker. Le Product Owner décrit un élément du backlog, l’équipe en discute, puis chacun choisit une valeur en privé. Tout le monde dévoile sa réponse en même temps afin que personne ne se laisse influencer par la voix la plus forte. Lorsque les estimations la plus élevée et la plus basse divergent, les personnes concernées expliquent leur raisonnement — et cette conversation, qui met en lumière les hypothèses et la complexité cachée, a généralement plus de valeur que le chiffre final. Pour un guide plus détaillé, consultez comment utiliser le planning poker dans l’estimation agile.

Des points à la vitesse

Une fois qu’une équipe estime ses tâches en points, elle peut mesurer sa vélocité : le nombre de points qu’elle réalise au cours d’un sprint. Après quelques sprints, la vélocité moyenne devient une prévision simple et empirique : si une équipe termine régulièrement environ 30 points par sprint, le Product Owner peut estimer approximativement quelle part du backlog pourra être traitée au cours des prochains sprints. La vélocité est une aide à la planification pour une seule équipe, jamais un objectif ni une comparaison entre équipes ; dès qu’elle devient un objectif, les équipes gonflent leurs estimations et ce chiffre perd tout son sens.

Les points d’histoire et la rétrospective

L’estimation est l’un des éléments les plus fréquemment examinés par une équipe lors de sa rétrospective de sprint. Lorsque les tâches sont systématiquement sous-estimées ou surestimées, lorsque la vélocité varie de manière excessive ou lorsque le travail « terminé » fait l’objet de nouvelles ouvertures, c’est lors de la rétrospective que l’équipe réajuste sa perception commune de l’ampleur des tâches et affine la manière dont elle découpe le travail. C’est grâce à cette boucle de rétroaction que la précision des estimations s’améliore, et non en redoublant d’efforts dès le départ.

Foire aux questions sur les points d’histoire

Que sont les points d’histoire dans la méthode agile ?

Les points d’histoire constituent une unité d’estimation relative qui exprime l’effort que demandera une tâche, en combinant sa complexité, le volume de travail et son degré d’incertitude en un seul chiffre. Ils ne constituent délibérément pas une mesure du temps. Une équipe compare chaque élément à d’autres dont elle a déjà évalué la taille et attribue des points sur une échelle commune, de sorte que les estimations reflètent la difficulté plutôt que le nombre d’heures qu’une personne en particulier pourrait y consacrer.

Pourquoi utiliser des points d’histoire plutôt que des heures ?

Les gens ont du mal à estimer la durée absolue d’une tâche, mais ils savent bien déterminer si une tâche est plus importante qu’une autre. Les points de story s’appuient sur cette force. Ils évitent également le piège qui consiste à considérer une estimation comme un engagement, tiennent compte du fait que la même tâche prend plus ou moins de temps selon les personnes, et intègrent la complexité et le risque — et pas seulement la durée. Au fil de quelques sprints, la vélocité d’une équipe en points devient une prévision plus fiable que la somme des estimations en heures.

Comment évaluez-vous les points d’histoire ?

La plupart des équipes utilisent le « planning poker ». Le Product Owner présente un élément du backlog, l’équipe en discute, puis chacun choisit en privé une valeur sur une échelle commune — généralement une suite de type Fibonacci (1, 2, 3, 5, 8, 13). Tout le monde dévoile son choix en même temps ; lorsque les estimations divergent fortement, les personnes ayant donné les notes les plus élevées et les plus basses expliquent leur raisonnement et l’équipe vote à nouveau jusqu’à ce que les avis convergent. La discussion qui met en lumière la complexité cachée est souvent plus précieuse que le chiffre lui-même.

Peut-on comparer les points de story entre les équipes ?

Non. Un point d’histoire est calibré en fonction de la perception qu’a une équipe de la taille relative d’une tâche ; ainsi, un « 5 » pour une équipe n’est pas un « 5 » pour une autre. Comparer la vélocité ou le total de points entre les équipes n’a aucun sens et, si cela est utilisé comme objectif, cela s’avère carrément néfaste : cela pousse les équipes à gonfler leurs estimations. Les points de story constituent un outil de planification destiné aux prévisions d’une seule équipe, et non un indicateur de productivité à des fins de comparaison.

Lectures complémentaires