Story points : estimer sans se mentir

Un story point n'est pas une heure déguisée. C'est une mesure relative de taille qui sert à une seule chose : prévoir combien de travail une équipe peut absorber par cycle. Dès qu'on lui demande autre chose, le système se corrompt.

Définition

Un story point est une unité de mesure relative, sans dimension, qui exprime l'effort total pour livrer un élément du backlog : la quantité de travail, la complexité, et l'incertitude, combinées en un seul chiffre.

La clé est le mot relative. Un point n'a pas de valeur absolue. Ce qui compte, c'est qu'une tâche de 8 points soit vraiment environ deux fois plus grosse qu'une tâche de 5 et huit fois plus qu'une tâche de 1.

Pourquoi pas simplement des heures ?

Parce que les humains sont mauvais pour estimer des durées absolues, et bons pour comparer des tailles. Demandez à quelqu'un combien de minutes il met pour aller au travail : il se trompera. Demandez-lui si c'est plus long que d'aller à l'épicerie : il aura raison.

Trois autres raisons, plus pratiques :

Une heure n'est pas une heure. Un développeur senior et un junior ne mettent pas le même temps sur la même tâche. Le point, lui, est la propriété de la tâche, pas de la personne.
Les heures invitent la négociation. « Tu as dit 6 heures, il en reste 2, ça devrait passer. » Personne ne négocie un 5 en 3.
Le point encaisse l'incertitude. Une tâche simple mais floue mérite un chiffre plus élevé. En heures, cette nuance disparaît.

Pourquoi la suite de Fibonacci

L'échelle habituelle est 1, 2, 3, 5, 8, 13, 21 — une variante de la suite de Fibonacci. Les écarts se creusent volontairement à mesure que les tâches grossissent, parce que la précision de l'estimation baisse avec la taille.

Autrement dit : distinguer 1 de 2 est utile et faisable ; débattre entre 20 et 21 sur une grosse tâche est du temps perdu, puisque l'incertitude dépasse largement l'écart. L'échelle vous empêche d'avoir cette conversation.

Règle de terrain : au-delà de 13, on ne l'estime pas, on la découpe. Un élément à 21 points est un aveu qu'on ne le comprend pas encore.

Le planning poker, en pratique

Le Product Owner présente l'élément et répond aux questions.
Chaque développeur choisit une carte, face cachée.
Tout le monde révèle en même temps — c'est le point essentiel, il évite l'ancrage sur l'avis du plus ancien.
Si les chiffres divergent fortement, les extrêmes expliquent leur raisonnement. C'est là qu'est la valeur : l'écart révèle presque toujours une exigence comprise différemment, pas un désaccord d'estimation.
On revote. Deux tours suffisent généralement.

L'estimation n'est pas le produit de l'exercice. La conversation l'est. Une équipe qui converge instantanément sur chaque élément ne discute probablement pas assez.

Établir votre échelle de référence

Prenez une tâche déjà livrée, petite, bien comprise de tous, et déclarez-la « 2 ». Toutes les estimations suivantes se font par comparaison avec elle. Cette référence appartient à l'équipe : elle n'est pas transférable, ce qui explique pourquoi comparer la vélocité de deux équipes n'a aucun sens.

La vélocité, et le piège

La vélocité est la somme des points terminés par sprint, moyennée sur les trois à cinq derniers. Elle sert à une chose : prévoir ce qui tient dans le prochain sprint, et donner une fourchette de date sur un ensemble de fonctionnalités.

Elle ne sert pas à mesurer la productivité. Voici pourquoi, mécaniquement : les points sont estimés par l'équipe elle-même. Le jour où on demande à une équipe d'augmenter sa vélocité, elle augmente ses estimations. Personne ne ment consciemment — c'est simplement que la pression déplace le curseur du « raisonnable ». Vous obtenez le même travail avec des chiffres plus gros, et vous avez détruit votre seul outil de prévision.

Quand une mesure devient un objectif, elle cesse d'être une bonne mesure.

Corollaire : ne comparez jamais la vélocité de deux équipes. Leurs échelles de référence sont différentes. C'est comme comparer des températures en Celsius et en Fahrenheit sans conversion.

Faut-il estimer du tout ?

Question légitime. Le mouvement #NoEstimates propose de compter simplement le nombre d'éléments livrés par sprint. Sur des backlogs où les éléments sont découpés à taille comparable, cette méthode prédit aussi bien que les points, pour un coût nul.

Notre position : estimez quand l'estimation change une décision — arbitrer entre deux fonctionnalités, valider une date de lancement, décider de bâtir ou d'acheter. Si l'estimation ne change aucune décision, elle est un rituel coûteux. La question à poser en réunion n'est pas « combien de points ? » mais « qu'est-ce que ce chiffre va nous faire décider ? ».

Ce qu'on fait chez Groupe Bilbs

On estime pour donner une fourchette honnête, pas pour se protéger. Nos plans contiennent un délai réaliste jusqu'à la production et une cible chiffrée, décidés avant la première ligne de code. Si la cible qu'on nous demande d'atteindre nous semble irréaliste, on le dit dans le plan — pas après la facture.

Questions fréquentes

Un story point, ça vaut combien d'heures ?

Rien de fixe, et c'est volontaire. Un point est une mesure relative de taille, propre à une équipe. Convertir les points en heures rétablit exactement les problèmes que les points servaient à éviter : la négociation ligne par ligne et la comparaison entre personnes.

Pourquoi utiliser la suite de Fibonacci pour estimer ?

Parce que la précision d'une estimation baisse quand la tâche grossit. Les écarts croissants de la suite empêchent de débattre entre 20 et 21, un débat sans valeur, tout en gardant de la finesse sur les petites tâches où la distinction est réelle.

Comment calcule-t-on la vélocité d'une équipe ?

En additionnant les points des éléments réellement terminés à chaque sprint, puis en faisant la moyenne des trois à cinq derniers sprints. Seul ce qui répond à la définition de « fini » compte : un élément à 80 % vaut zéro point.

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

Non. Chaque équipe fixe sa propre échelle de référence, donc les points d'une équipe ne sont pas commensurables avec ceux d'une autre. Comparer les vélocités pousse mécaniquement à l'inflation des estimations et détruit leur utilité de prévision.

Quelle est la plus grosse taille estimable en story points ?

En pratique, 13. Au-delà, l'usage est de découper l'élément plutôt que de l'estimer : une tâche à 21 points signale surtout qu'elle est encore mal comprise.

Parlons de votre projet

Vous voulez une fourchette honnête sur un projet logiciel plutôt qu'un chiffre de vendeur ? Décrivez-nous le problème — la séance de direction IA vous donne un plan et une fourchette avant tout engagement.

A story point is not an hour in disguise. It is a relative measure of size that serves one purpose: forecasting how much work a team can absorb per cycle. Ask it to do anything else and the system corrupts.

Definition

A story point is a relative, dimensionless unit expressing the total effort to deliver a backlog item: amount of work, complexity, and uncertainty, combined into one number.

The key word is relative. A point has no absolute value. What matters is that an 8-point item really is about twice the size of a 5 and eight times a 1.

Why not just use hours?

Because humans are bad at estimating absolute durations and good at comparing sizes. Ask someone how many minutes their commute takes and they will be wrong. Ask whether it is longer than a trip to the grocery store and they will be right.

Three more practical reasons:

An hour is not an hour. A senior and a junior do not take the same time on the same task. A point is a property of the task, not of the person.
Hours invite negotiation. "You said 6 hours, 2 are left, you should make it." Nobody negotiates a 5 down to a 3.
Points absorb uncertainty. A simple but vague task deserves a higher number. In hours, that nuance disappears.

Why the Fibonacci scale

The usual scale is 1, 2, 3, 5, 8, 13, 21 — a Fibonacci variant. The gaps widen deliberately as items grow, because estimation accuracy falls with size.

Put differently: telling a 1 from a 2 is useful and doable; arguing 20 versus 21 on a large item is wasted time, since the uncertainty dwarfs the gap. The scale stops you from having that conversation.

Field rule: above 13, do not estimate it — split it. A 21-point item is an admission you do not understand it yet.

Planning poker, in practice

The Product Owner presents the item and answers questions.
Each developer picks a card, face down.
Everyone reveals simultaneously — this is the essential part; it prevents anchoring on the most senior voice.
If numbers diverge sharply, the outliers explain their reasoning. That is where the value is: the gap almost always reveals a requirement understood differently, not an estimation disagreement.
Re-vote. Two rounds usually suffice.

The estimate is not the output of the exercise. The conversation is. A team that converges instantly on every item probably is not discussing enough.

Setting your reference scale

Take a small, already-delivered item everyone understands and declare it a "2". Every later estimate is made by comparison against it. That reference belongs to the team and is not transferable, which is exactly why comparing two teams' velocity is meaningless.

Velocity, and the trap

Velocity is the sum of points completed per sprint, averaged over the last three to five. It serves one purpose: forecasting what fits in the next sprint, and giving a date range for a set of features.

It does not measure productivity. Here is the mechanism: points are estimated by the team itself. The day you ask a team to raise its velocity, it raises its estimates. Nobody lies consciously — pressure simply shifts where "reasonable" sits. You get the same work with bigger numbers, and you have destroyed your only forecasting tool.

When a measure becomes a target, it ceases to be a good measure.

Corollary: never compare two teams' velocity. Their reference scales differ. It is comparing Celsius to Fahrenheit without converting.

Should you estimate at all?

A fair question. The #NoEstimates movement proposes simply counting items delivered per sprint. On backlogs where items are split to comparable size, that predicts about as well as points, at zero cost.

Our position: estimate when the estimate changes a decision — choosing between two features, committing to a launch date, deciding build versus buy. If the estimate changes no decision, it is an expensive ritual. The question to ask in the room is not "how many points?" but "what will this number make us decide?"

How we do it at Groupe Bilbs

We estimate to give an honest range, not to cover ourselves. Our plans contain a realistic time-to-production and a quantified target, both set before the first line of code. If the target we are asked to hit looks unrealistic, we say so in the plan — not after the invoice.

Frequently asked questions

How many hours is a story point?

Nothing fixed, and that is deliberate. A point is a relative measure of size, specific to one team. Converting points into hours reinstates exactly the problems points were meant to avoid: line-by-line negotiation and comparison between people.

Why use the Fibonacci sequence for estimating?

Because estimation accuracy drops as items grow. The widening gaps prevent a valueless debate between 20 and 21 while keeping precision on small items where the distinction is real.

How do you calculate a team's velocity?

Add up the points of items actually completed each sprint, then average the last three to five sprints. Only work meeting the definition of done counts: an item at 80 percent is worth zero points.

Can you compare velocity between two teams?

No. Each team sets its own reference scale, so one team's points are not commensurable with another's. Comparing velocities mechanically drives estimate inflation and destroys their forecasting value.

What is the largest size worth estimating in story points?

In practice, 13. Beyond that the convention is to split the item rather than estimate it: a 21-point item mostly signals that it is still poorly understood.

Let's talk about your project

Want an honest range on a software project rather than a sales number? Describe the problem — the AI Direction Session gives you a plan and a range before any commitment.

Story points :
estimer sans se mentir.