La velocity est devenue la métrique reine du développement logiciel. Elle mesure la productivité de l'équipe, justifie les planifications, rassure le management. Elle mesure aussi quelque chose que personne ne sait vraiment définir.

Il y a une réunion de planification de sprint qui se tient en ce moment même dans quelques centaines d’entreprises. L’équipe est réunie, le backlog est ouvert. Et quelque part dans la salle, quelqu’un dit : « Si on veut tenir notre velocity, on devrait se limiter à 40 points ce sprint. »

Ce que cette phrase révèle : l’équipe ne planifie pas pour livrer de la valeur. Elle planifie pour maintenir un chiffre stable.

C’est le velocity game. Et c’est l’une des pathologies les plus répandues du Scrum en entreprise.

D’où vient la velocity

La velocity est née d’une bonne intuition : mesurer la capacité d’une équipe à livrer du travail sur une période donnée, pour planifier les périodes suivantes de manière réaliste.

L’idée de base est saine. Si une équipe livre en moyenne 35 points de story par sprint depuis trois mois, on peut raisonnablement planifier les prochains sprints à 35 points. C’est de la prédictibilité empirique, pas de la planification au doigt mouillé.

Le problème commence quand cette métrique de prédiction devient une métrique d’évaluation.

Comment la velocity devient une cible

La loi de Goodhart dit à peu près : quand une mesure devient un objectif, elle cesse d’être une bonne mesure.

C’est exactement ce qui se passe avec la velocity.

Au début : l’équipe estime les tickets en story points pour planifier réalistement. La velocity est observée, pas pilotée.

Quelques mois plus tard : le manager commence à regarder la velocity dans les rapports Jira. Il demande si la baisse de velocity d’un sprint est « préoccupante ». L’équipe commence à défendre sa velocity en réunion.

Un an plus tard : l’équipe estime les tickets en choisissant des valeurs qui maintiennent la velocity stable. Les gros tickets sont découpés pour rester sous un seuil confortable. Les petits tickets sont groupés pour atteindre le minimum. Les critères d’acceptation s’ajustent en fonction des points disponibles plutôt que des besoins réels.

La velocity est maintenant un objectif. Et comme objectif, elle pousse l’équipe à optimiser pour elle-même, pas pour la valeur livrée.

Le Scrum théâtre

Le velocity game est l’un des symptômes du Scrum théâtre : le fait de respecter les formes d’une méthode sans en retenir l’esprit.

Le Scrum théâtre ressemble à ça :

Des daily standups de quinze minutes qui durent quarante-cinq minutes et se terminent par « bon, on se reparle en DM ». Tout le monde répond aux trois questions rituelles. Personne ne signale vraiment ce qui bloque.

Des sprint reviews où l’équipe présente ce qui a été livré mais où les parties prenantes ne donnent pas de vrai feedback parce que les décisions importantes ont déjà été prises ailleurs.

Des rétrospectives où les mêmes problèmes sont listés chaque sprint, avec les mêmes actions qui ne sont jamais mises en place parce qu’elles nécessiteraient des changements structurels que le Scrum Master n’a pas le mandat de faire.

Une planification de sprint où les tickets sont estimés en sept minutes chacun parce qu’il y en a trop et que la réunion doit finir avant midi.

La forme est là. Le fond a disparu.

Ce que les cycles peuvent faire différemment

Un cycle n’est pas forcément meilleur qu’un sprint. Ce n’est pas une méthode avec un manuel d’utilisation. C’est simplement une période de temps délimitée pour organiser le travail.

Ce que ça ouvre comme possibilité : définir le cycle en fonction du besoin plutôt qu’en fonction d’une cadence imposée.

Un cycle peut durer deux semaines, quatre semaines, six semaines - selon ce qu’il y a à faire et comment l’équipe travaille. Il peut avoir une thématique : « Ce cycle, on se concentre sur la performance de la page d’accueil. » Il peut avoir un objectif mesurable : « À la fin de ce cycle, le temps de chargement est sous 2 secondes. »

La différence fondamentale : le cycle est défini par son objectif, pas par sa durée. La durée est une contrainte qui aide à définir un objectif atteignable, pas l’inverse.

L’estimation sans story points

Une des façons de sortir du velocity game est de changer la façon d’estimer.

Les story points sont censés représenter la complexité relative du travail, pas le temps. En pratique, dans la plupart des équipes, ils représentent le temps. Et ils sont manipulés en fonction de la velocity cible.

Des alternatives qui ont montré leur efficacité dans certaines équipes :

Le T-shirt sizing. XS, S, M, L, XL. Moins précis, mais plus honnête sur la nature de l’estimation. On ne prétend pas savoir si quelque chose prend 3 points ou 5 points. On sait si c’est petit, moyen ou grand.

L’estimation probabiliste. Plutôt qu’un chiffre, une fourchette : « Ce travail prend entre 2 et 5 jours selon les surprises qu’on rencontre. » Plus réaliste, moins manipulable.

Pas d’estimation du tout. Certaines équipes, notamment dans le mouvement #NoEstimates, ont simplement arrêté d’estimer à ce niveau de granularité. Elles suivent le nombre d’issues terminées par période plutôt que des points hypothétiques.

Aucune de ces approches n’est universellement meilleure. Ce qui est universellement vrai : toute métrique d’estimation peut être jouée si elle devient une métrique de performance.

Ce que l’objectif de cycle déplace

Quand un cycle a un objectif clair - un résultat attendu, pas juste une liste de tickets - quelque chose change dans la façon dont l’équipe prend des décisions en cours de route.

Avec une velocity à maintenir : chaque décision est filtrée par « est-ce que ça me fait avancer vers mes points ? ». Une issue imprévue importante mais hors scope du sprint crée une tension. Si on la prend, on rate la velocity. Si on ne la prend pas, on ignore quelque chose d’important.

Avec un objectif de cycle : chaque décision est filtrée par « est-ce que ça me fait avancer vers l’objectif ? ». Une issue imprévue importante est soit dans le périmètre de l’objectif (on la prend), soit hors périmètre (on la note pour le cycle suivant). L’arbitrage est plus naturel.

L’objectif de cycle donne aussi un critère de succès indépendant des métriques de livraison. « Avons-nous atteint l’objectif de ce cycle ? » est une question à laquelle on peut répondre par oui ou non, avec des arguments substantiels. « Avons-nous maintenu notre velocity ? » est une question à laquelle on peut toujours répondre oui si on a suffisamment bien paramétré les estimations.

Les rituels qui ont du sens

Ce n’est pas parce que le Scrum théâtre existe que tous les rituels Scrum sont inutiles. Certains ont une valeur réelle, à condition d’être pratiqués pour la bonne raison.

La synchronisation quotidienne a de la valeur quand elle sert à détecter les blocages réels. Pas à faire un rapport. La question utile n’est pas « qu’est-ce que tu as fait hier ? » mais « est-ce que quelque chose t’empêche d’avancer aujourd’hui ? ».

La revue de fin de cycle a de la valeur quand elle produit un feedback réel de la part de personnes qui utilisent ou vont utiliser ce qui a été livré. Pas une démo pour valider que les tickets sont fermés.

La rétrospective a de la valeur quand elle produit des actions concrètes avec un responsable et une échéance. Pas une liste de points positifs et négatifs qui disparaît dans Confluence.

Ce que ces rituels ont en commun quand ils fonctionnent : ils produisent des décisions, pas des comptes-rendus.

La question que peu d’équipes se posent

À la fin d’un cycle, quelle question l’équipe se pose-t-elle ?

Dans beaucoup d’équipes Scrum : « Avons-nous fermé les tickets prévus ? » Si oui, le cycle est un succès. Si non, on cherche ce qui a bloqué.

Une question plus utile : « Qu’est-ce que les utilisateurs peuvent faire maintenant qu’ils ne pouvaient pas faire avant ce cycle ? »

Si la réponse est vide - si tout ce qui a été fait pendant le cycle est de la dette technique, de la refactorisation interne, de l’infrastructure - ce n’est pas nécessairement un problème. Mais c’est une information. Elle dit que ce cycle n’a pas créé de valeur directe pour les utilisateurs, et que l’équipe devrait pouvoir expliquer pourquoi c’était le bon choix.

Si la réponse est là mais vague - « on a amélioré les performances globales » - c’est aussi une information. Elle dit que l’équipe a du mal à articuler la valeur de ce qu’elle livre.

La capacité à répondre clairement à cette question est l’un des meilleurs indicateurs de la santé d’une équipe de développement.

Sortir du velocity game sans tout casser

La plupart des équipes ne peuvent pas abandonner les story points demain. Ils sont dans les rapports, dans les engagements envers le management, dans les habitudes de travail depuis des années.

Ce qui peut changer progressivement :

Commencer par ajouter un objectif explicite à chaque cycle, même si on garde les points. L’objectif devient la conversation principale. Les points restent pour la prédictibilité.

Réduire le nombre de tickets par cycle plutôt que d’augmenter les estimations. Moins de tickets, mieux définis, avec des critères d’acceptation précis.

Évaluer le cycle sur son objectif atteint, pas sur sa velocity. Progressivement, le regard de l’équipe se déplace.

La velocity peut rester comme indicateur de capacité. Mais quand l’objectif du cycle devient le critère de succès principal, le velocity game perd son intérêt.

Le problème n’est pas le sprint. C’est de confondre la durée du sprint avec l’objectif du sprint. Et de confondre la velocity avec la valeur.

Un cycle bien défini n’a pas besoin de 42 points pour savoir s’il a réussi. Il a besoin d’une question claire : à la fin, qu’est-ce qu’on aura livré, et à qui ça sert ?

Cycles sans velocity game : sortir du Scrum théâtre