Pourquoi estimons-nous?

Bien sûr, pour la prévisibilité, mais encore? Personnellement, une partie de la réponse vient de certaines frictions dans le fonctionnement d’une entreprise.

Si je vous parle d’une équipe de développement qui itère régulièrement sur son produit, ce qu’elle développe et va valider souvent avec l’utilisateur si elle a fait la bonne chose ; considérez-vous cette équipe Agile? Quand même oui!

Si je vous parle d’une entreprise qui définit un budget développement pour l’année au complet, qui prend le temps de tout estimer pour déterminer la date de livraison 10 mois à l’avance, et dont le travail sera divisé en 15 sprints ; considérez-vous l’entreprise Agile? Pas vraiment. Ce que je viens de décrire, c’est du waterfall en sprints!

Bien que l'agilité apporte de nombreux avantages au développement logiciel, un défi persiste. Les équipes agiles travaillent souvent dans des entreprises qui ne le sont pas. Leur approche, basée sur l'adaptation et les petits incréments, se heurte à des pratiques rigides, comme les budgets annuels, les dates fixes de livraison ou les décisions hiérarchiques axées sur la planification à long terme. Ce décalage complexifie l'alignement entre la philosophie Agile des équipes et la culture globale de l'organisation.

Et ce besoin de prévisibilité, on le retrouve tout autant dans une entreprise en démarrage. Sauf qu'ici, la contrainte n'est pas un plan sur plusieurs mois, mais un budget limité. L'estimation sert alors à répondre à une question très concrète : «Est-ce que le travail qu'on planifie correspond au budget dont nous disposons?»

Pour pallier cet enjeu, les équipes vont généralement se diriger vers des outils d'estimation Agile. Ceux-ci ont pour objectif d’offrir davantage de visibilité quant à l’avancement du projet tout en évitant de donner des chiffres contraignants.

C’est avec ces techniques que Nexapp a commencé le développement de produits pour ses clients. Avec le temps, cependant, notre façon de faire a évolué pour offrir davantage de clarté et de prévisibilité à nos clients. Voyons ensemble les différentes techniques d’estimation utilisées à travers les années et ce qui nous a amenés à notre solution courante!

Points de récit (Story Points)

Comme beaucoup d’équipes agiles, l’approche par défaut lorsqu’il faut estimer les tâches d’un sprint est l’utilisation des «Story Points». Ils ne représentent pas une durée fixe, mais plutôt une évaluation relative basée sur la complexité, l'incertitude et le volume de travail. L'équipe attribue des points en comparant les tâches entre elles, souvent lors d'une session de planification (comme le poker planning par exemple). Les story points utilisent souvent la suite de Fibonacci (1, 2, 3, 5, 8, 13, etc.) pour estimer l'effort, car cette progression reflète mieux l'incertitude croissante avec l'augmentation de la complexité.

Avantages

Le principal avantage de cette approche est que les valeurs ne sont pas sous forme de temps, mais de complexité. L’un des enjeux d’estimation en temps est qu’il s’agit d’une valeur fixe. Il suffit qu’une tâche prenne plus de temps qu’estimé et toutes les estimations sont décalées. En estimant par complexité, l’équipe a davantage de flexibilité sur la manière dont la tâche sera réalisée et par qui.

Lorsqu’une équipe utilise les story points comme outil d’estimation, il est nécessaire que ses membres s’assoient ensemble et évaluent chaque tâche pour déterminer son niveau de complexité. Ces activités d’estimation (poker planning, raffinement technique, etc.) apportent une très grande valeur au projet, car elles amènent une mise à niveau de la compréhension des membres de l’équipe sur le travail à réaliser. C’est à ce moment que les inconnus sont généralement identifiés.

Conseil : Les inconnus dans les tâches à réaliser sont la principale source de retard dans le développement d’un produit. Plus tôt ces inconnus sont découverts dans le processus, plus l'équipe sera efficace pour les gérer et plus les estimations auront de la valeur.

Inconvénients

Un enjeu que nous avons souvent rencontré avec les story points concernait la compréhension de cette approche par nos clients. Étant relativement abstraite par rapport au concept de temps, l’utilisation des story points demande une bonne compréhension de son fonctionnement. Lors d’une rencontre que j’ai eue avec un client, nous avons dû lui expliquer qu’une tâche de 5 points n’équivalait pas à 5 tâches de 1 point. Ce dernier voyait une vélocité de 25 points et considérait cette valeur comme linéaire alors que ce n’est pas le cas avec cette approche. Il faut tenir compte du contenu d’un sprint pour interpréter une vélocité d’équipe. Une vélocité de X points sera relativement fiable lorsque, d’un sprint à l’autre, il y a environ le même nombre de tâches de 1 point, 2 points, 3 points, etc. Si la structure des sprints n’est jamais uniforme, est-ce que la vélocité de l’équipe en story points est réellement fiable?

Le fait qu’une valeur en story points ne signifie pas une durée, mais bien un niveau de complexité rend cette approche d’estimation peu fiable. En effet, une tâche complexe peut aussi bien prendre quelques jours que plusieurs semaines à réaliser. Cette variation peut venir de qui réalise la tâche : est-ce une personne récemment arrivée sur le projet? Une personne d’expérience dans la technologie? Un développeur ou une développeuse qui vient de terminer ses études? Il y a plusieurs facteurs qui peuvent influencer le temps que la tâche prendra. Si le temps n'a aucun rapport avec cette unité de mesure, pourquoi l'utilise-t-on pour déterminer la vélocité?

Pour pallier ce problème, certaines équipes associent un nombre d'heures aux story points pour faciliter l'estimation, en se demandant si une tâche est réalisable en X heures. Cependant, cette pratique ouvre la porte à la microgestion. J'ai observé un gestionnaire qui consultait le nombre d'heures travaillées par chaque membre de l’équipe et les associait à des tâches pour "remplir leur temps". Dans ce contexte, la vélocité et les story points ne servaient plus à l'équipe pour l'estimation, mais au gestionnaire pour décider qui travaillerait sur quoi. Résultat : avec chacun sa liste de tâches assignées, il devenait impossible de travailler efficacement en équipe.

Bien que cette méthode d’estimation apporte des conversations intéressantes lors du raffinement technique, son haut niveau d’abstraction limitait son efficacité. De plus, cette approche demande une bonne gymnastique mentale pour être comprise. 

C’est pourquoi certaines équipes de Nexapp sont passées à la prochaine approche pour régler certains de ces enjeux.

T-shirt Sizing

L'utilisation du T-shirt Sizing est très similaire à l'approche par Story Points. On pourrait même dire qu'ils sont interchangeables, car il est possible d'associer une taille de chandail à un nombre de points de complexité. Par exemple, une tâche de 1 point pourrait correspondre à une tâche "petite", une tâche de 3 points à une tâche "moyenne" et ainsi de suite :

Petit (S)

• Faible complexité, effort et risque
• Peut être réalisée rapidement, souvent en quelques heures ou en une journée
• Nécessite peu de collaboration ou de dépendances

Moyen (M)

• Complexité, effort ou risque modérés
• Peut prendre un ou deux jours à réaliser
• Peut nécessiter une certaine collaboration ou impliquer des dépendances mineures

Grand (L)

• Forte complexité, effort ou risque
• Peut nécessiter plusieurs jours pour être complétée ou s'étendre sur plusieurs sprints (si non découpée)
• Implique une collaboration importante, des dépendances ou des zones d'incertitude

Avantages

Malgré cette ressemblance, l'approche par T-shirt Sizing résout certains problèmes de l'approche par Story Points. En effet, elle retire le concept de valeur numérique non linéaire pour estimer la complexité. Une vélocité de 15 points peut grandement varier en fonction de la composition de ces points. En T-shirt Sizing, la vélocité est plus explicite : "Dans un sprint de 2 semaines, l'équipe peut généralement compléter 5 tâches petites, 3 tâches moyennes et une tâche grande."

En changeant d'approche d'estimation, nous avons résolu beaucoup de problèmes avec nos clients. Il y avait beaucoup moins de mauvaises interprétations de notre méthode de travail de la part des personnes non familières avec le développement logiciel.

Inconvénients

Cependant, cette approche conserve certains défauts de l'approche par Story Points. La définition des tailles de chandail reste très abstraite et vague. Selon les critères énumérés plus haut, la portée d'une unité d'estimation est assez large.

Certaines équipes utilisent davantage d'unités de mesure, telles que Très petit (XS) et Très grand (XL). L'enjeu avec un plus grand nombre d'unités est que cela complexifie la définition de la vélocité de l'équipe. Prenons l'exemple d'une équipe qui réalise des sprints d'environ 15 tâches :

En utilisant 5 unités de complexité, cela complexifie la définition de la vélocité d'équipe, car il devient difficile de comparer les unités lors de la préparation d'un sprint. Plus il y a d'unités, plus la comparaison devient fréquente et laborieuse.

De plus, il y a le problème de la composition variable : que faire lorsque la vélocité d'équipe inclut des tâches XL alors qu'il n'y a aucune tâche de cette taille à réaliser prochainement? Par quoi remplace-t-on cette valeur dans notre calcul de vélocité?

Ces variations possibles rendent l'estimation globale de l'équipe beaucoup plus compliquée, car la valeur numérique de cette approche devient secondaire face à la nécessité constante d'analyser la composition détaillée des sprints.

Cette complexité nous a amenés à une réflexion importante : si une approche d'estimation est difficile à expliquer et à appliquer de manière cohérente, peut-être qu'elle est trop compliquée pour un besoin initial simple, soit avoir une estimation pour améliorer la prédictibilité. C'est cette réflexion qui nous a poussés vers notre prochaine approche.

Débit

Le manque de fiabilité de l’approche par Story Points et le haut niveau d’abstraction de l’approche par T-shirt Sizing nous ont amenés à chercher une alternative. Nous avions besoin d’une approche explicite et qui ne laisse aucune place à l’interprétation. Parallèlement à cette réflexion, nous nous intéressions de plus en plus à l’efficacité des équipes, un concept au cœur de la philosophie Lean. Cette dernière, issue du monde manufacturier, a été popularisée dans le développement logiciel par la méthode Kanban, qui met l'accent sur la visualisation du flux de travail pour améliorer l'efficacité.

Pour mesurer et optimiser ce flux, des métriques clés issues du Lean ont été adoptées, telles que le travail en cours (WIP), le débit et le temps de cycle. Ces indicateurs, provenant à l'origine du secteur manufacturier, permettent d'identifier les goulots d'étranglement, de réduire les temps d'attente et ainsi de fluidifier la livraison de valeur. L'influence du Lean a ainsi profondément modifié les pratiques de développement logiciel en encourageant une culture d'amélioration continue.

L'approche Lean repose sur un principe fondamental : optimiser pour réduire le gaspillage. Dans cette optique, toute activité n'apportant pas de valeur directe au client est considérée comme superflue. L'estimation des tâches, par sa nature même, est donc remise en question, car elle ne contribue pas directement au produit final pour lequel le client paie.

C'est dans cette philosophie que nous avons adopté l'approche par débit (throughput). Plutôt que d'estimer la complexité de chaque tâche, nous nous concentrons sur le nombre de tâches que l'équipe peut livrer par unité de temps. Cette méthode repose sur undécoupage uniforme des tâches : chaque élément de travail doit représenter approximativement la même quantité d'effort.

Avantages

Le principal avantage de cette approche est sa simplicité et sa transparence. Fini les débats sur la différence entre une tâche de 3 points et une de 5 points. Une tâche équivaut à une unité de travail. La vélocité devient immédiatement compréhensible : "Cette équipe livre en moyenne 12 tâches par sprint de 2 semaines."

Cette approche élimine également le biais d'estimation. Plutôt que de prédire l'effort avant de commencer, nous mesurons ce qui est réellement livré. Les données historiques deviennent notre outil de prédiction le plus fiable.

Le découpage uniforme des tâches, bien qu'exigeant au début, devient rapidement naturel avec les bonnes techniques. Chez Nexapp, par exemple, nous utilisons la méthode SPIDR pour diviser efficacement les récits utilisateurs en tâches de taille similaire. Cette méthode structurée (Spike, Path, Interface, Data, Rules) offre un cadre concret pour identifier les différentes facettes d'une fonctionnalité et les découper de manière cohérente.

La prévisibilité s'en trouve grandement améliorée. Avec 50 tâches dans le backlog et un débit de 12 tâches par sprint, nous pouvons estimer qu'il faudra environ 4 sprints pour terminer, soit 8 semaines. Cette simplicité de calcul facilite énormément les discussions avec les parties prenantes.

Inconvénients

Le défi principal de cette approche réside dans le découpage uniforme des tâches. Il faut développer une discipline pour s'assurer que chaque tâche représente une quantité de travail similaire. Cela demande de l'expérience et parfois de revoir notre façon de structurer le travail.

Certaines tâches, par nature, ne peuvent pas être découpées aussi finement que d'autres. Une migration de base de données ou l'intégration d'un système externe peut difficilement être réduite à la même granularité qu'une correction de bogue. Dans ces cas, nous identifions ces tâches comme des "épiques" qui comptent pour plusieurs unités dans notre débit.

L'approche demande aussi une maturité d'équipe dans le découpage technique. Les développeurs doivent apprendre à identifier rapidement quand une tâche est trop grosse et comment la subdiviser efficacement.

Comparaison des approches

Conclusion

Notre parcours d'évolution des méthodes d'estimation chez Nexapp illustre une tendance plus large dans l'industrie : le passage de la complexité vers la simplicité. Les Story Points, bien qu'utiles pour développer une culture d'estimation, créent souvent plus de confusion qu'ils n'en résolvent. Le T-shirt Sizing améliore la communication, mais reste trop abstrait.

L'approche par débit, inspirée du Lean, répond directement au besoin fondamental : offrir de la prévisibilité sans sacrifier l'agilité. En nous concentrant sur ce qui compte vraiment — la livraison régulière de valeur — nous avons trouvé un équilibre entre les attentes organisationnelles et les principes agiles.

Cette approche par débit est désormais notre référence chez Nexapp. Nos équipes internes l'utilisent systématiquement et elle nous permet d'offrir à nos clients la transparence et la prévisibilité qu'ils recherchent, tout en préservant notre agilité dans l'exécution.

Lorsque nos équipes rejoignent le développement chez nos clients, elles doivent parfois s'adapter aux pratiques d'estimation déjà en place. Cependant, nous aspirons toujours à faire évoluer ces pratiques vers notre approche par débit, en démontrant ses avantages concrets en termes de prévisibilité et de simplicité.

Nous restons constamment à l'affût des nouvelles pratiques et méthodologies qui émergent dans l'industrie. Comme le démontre notre évolution des Story Points vers le débit, nous n'hésitons pas à remettre en question nos méthodes et à les adapter si une approche plus efficace se présente.

Le choix de la méthode d'estimation doit servir votre contexte, pas l'inverse. L'important est de rester fidèle à l'objectif : créer de la transparence, faciliter la planification et, en fin de compte, livrer de la valeur de façon prévisible à vos clients.