J'ai arrêté les story points : ce qu'on a mis à la place

J'ai arrêté les story points. Personne dans l'équipe n'a demandé à les remettre.

Sur le papier, les story points sont une bonne idée. Une unité abstraite qui mesure la complexité sans se lier à une durée, en théorie pour éviter de promettre des délais qu'on ne tiendra pas.

En pratique, voici ce que j'observais.

Ce que je voyais sprint après sprint

30 minutes de poker planning pour estimer un ticket à 3 points. Le même ticket, livré en 4 heures ou en 3 jours selon qui le prenait. Une vélocité en points qu'on comparait sprint après sprint comme si c'était un indicateur fiable. Et des rétrospectives où on débattait du nombre de points plutôt que de ce qui avait réellement bloqué l'équipe.

On mesurait l'estimation, pas la livraison.

C'est le symptôme classique d'un outil qui a pris la place de l'objectif. Le point Fibonacci devient une fin en soi - on cherche à avoir raison sur le chiffrage plutôt qu'à livrer vite et apprendre du feedback réel. La précision de l'estimation est souvent inversement proportionnelle à la valeur livrée.

Ce qu'on a mis à la place : des tailles de tickets

S, M, L. C'est tout.

• S : moins d'une demi-journée.
• M : entre une demi-journée et deux jours.
• L : plus de deux jours - et dans ce cas, on découpe avant de commencer.

Pas de Fibonacci. Pas de consensus collectif sur un chiffre abstrait qui ne représente rien de concret pour personne dans la salle. Juste une question simple : est-ce que ce ticket est petit, moyen ou gros ?

Ce que ça a changé concrètement

Le planning prend 15 minutes au lieu d'une heure. Sans débat sur "5 points ou 8 points", la discussion se recentre sur ce qui compte : est-ce que le périmètre est clair, est-ce qu'il y a un risque technique identifié.

Les L sont systématiquement découpés. Ce qui force une meilleure compréhension du sujet avant même d'ouvrir l'IDE. Un ticket qu'on n'arrive pas à découper en S ou M cache généralement une ambiguïté fonctionnelle qu'il vaut mieux régler tout de suite plutôt que pendant le développement.

Les rétrospectives portent sur les vraies frictions. Plus de débat sur la précision des estimations passées. La conversation revient sur ce qui a réellement ralenti l'équipe - une dépendance externe, une spec incomplète, un existant mal compris.

L'équipe a adopté ce changement sans résistance, parce qu'au fond tout le monde savait que les story points ne servaient plus grand-chose. Personne n'avait osé le dire en premier.

Pourquoi ça fonctionne (et pourquoi ça ne conviendra pas à toutes les équipes)

Les story points ont une vraie utilité dans certains contextes : équipes matures avec un historique de vélocité stable, engagements contractuels qui nécessitent une granularité fine, ou organisations où plusieurs équipes doivent se comparer sur une métrique commune. Si ce contexte est le vôtre, ne jetez pas le système à la légère.

Mais pour la majorité des équipes produit en phase de croissance, la granularité fine des points n'apporte pas de valeur proportionnelle au temps qu'elle coûte. Ce qui compte réellement pour prioriser et planifier, c'est une distinction grossière : ce ticket se fait aujourd'hui, cette semaine, ou doit d'abord être découpé. S/M/L répond à cette question en quelques secondes, sans mécanique de consensus ni débat sur l'échelle.

C'est une différence de philosophie plus que de méthode : arrêter de mesurer la précision de l'estimation, et se concentrer sur la fluidité de la livraison.

Ce qu'un CTO hands-on tranche, et ce qu'il ne tranche pas seul

Ce genre de changement de process ne se décrète pas depuis un tableau de bord. Il se décide avec l'équipe qui va le vivre au quotidien, en observant ce qui bloque réellement la livraison plutôt qu'en appliquant une recette lue dans un livre sur l'Agile.

C'est une partie du rôle que j'assume dans les équipes que j'accompagne : rester au contact du code et du quotidien de l'équipe pour repérer quand un rituel a cessé de servir, et avoir la légitimité - parce qu'on est dans le contexte, pas au-dessus - de le simplifier sans perdre en visibilité sur la livraison.

La meilleure méthodologie est celle que votre équipe comprend et applique naturellement. Pas celle qui impressionne dans un livre sur l'Agile.

FAQ : abandonner les story points pour des tailles de tickets

Pourquoi arrêter les story points en Scrum ?

Parce que dans la pratique, ils mesurent la précision de l'estimation plutôt que la vélocité réelle de livraison. Le temps passé en poker planning à converger sur un chiffre Fibonacci dépasse souvent la valeur que ce chiffre apporte, et la vélocité en points devient un indicateur comparé sprint après sprint sans être réellement fiable.

Qu'est-ce que le système S/M/L en gestion de projet agile ?

C'est une estimation par taille de ticket en trois catégories : S (moins d'une demi-journée), M (entre une demi-journée et deux jours), L (plus de deux jours). Un ticket classé L est systématiquement redécoupé avant d'être pris en sprint, ce qui force à clarifier le périmètre en amont plutôt qu'en cours de développement.

Les tailles de tickets S/M/L remplacent-elles complètement les story points ?

Pas dans tous les contextes. Les story points gardent un intérêt pour des équipes matures avec un historique de vélocité stable, des engagements contractuels nécessitant une granularité fine, ou plusieurs équipes qui doivent se comparer sur une métrique commune. Pour la majorité des équipes produit en croissance, la granularité fine des points n'apporte pas de valeur proportionnelle à son coût en temps de réunion.

Combien de temps prend un planning de sprint sans story points ?

Dans l'équipe où ce changement a été mis en place, le planning est passé d'environ une heure à 15 minutes, en supprimant le débat de consensus sur un chiffre abstrait et en recentrant la discussion sur la clarté du périmètre et le découpage des tickets trop gros.

Comment faire adopter un changement de process comme celui-ci sans résistance d'équipe ?

En partant de ce que l'équipe observe déjà - ici, le décalage entre le temps passé à estimer et la valeur de l'estimation - plutôt qu'en imposant une méthodologie depuis le haut. Le changement fonctionne quand il répond à une friction que tout le monde ressent déjà mais que personne n'avait formulée.