Pourquoi nous travaillons en cycles courts avec #NoEstimates

Ce que les gros chiffrages racontent mal

Quand un client nous parle d’un nouveau produit, la question du délai arrive vite. C’est bien normal : il faut prévoir un budget, organiser le travail et savoir quand les premières personnes pourront utiliser le produit. Le premier réflexe est souvent de lister toutes les fonctionnalités imaginées, puis de placer un nombre de jours en face de chacune.

Ce travail aide à discuter du périmètre. Il devient beaucoup moins fiable lorsqu’on additionne ces chiffres pour annoncer une date. Un sujet volumineux contient toujours une part de découverte : une règle métier se précise en cours de route, une dépendance se révèle plus complexe ou un cas d’usage avait simplement échappé aux premières discussions. Sur plusieurs mois de travail, ces écarts finissent par compter.

À mesure que le planning glisse, la pression augmente. Les tests et les finitions risquent alors de servir de marge d’ajustement, l’équipe accumule du retard et le client attend plus longtemps un résultat parfois moins abouti. Nous essayons d’éviter cette situation en travaillant d’abord sur la taille des sujets, plutôt qu’en cherchant à mieux prédire de gros volumes.

Des tickets que l’on peut vraiment terminer

Nous prenons le temps de découper chaque sujet en étapes qui peuvent être développées, testées et livrées en un ou deux jours. Cette durée sert de repère. Lorsqu’un ticket paraît plus long, nous revenons au besoin avec le client et cherchons une première version plus petite qui lui apporte déjà quelque chose d’utile.

Nous évitons aussi de séparer le travail en un ticket backend puis un ticket frontend. Prenons l’annulation d’un rendez-vous : le ticket décrit ce que la personne doit pouvoir faire, et le développeur s’occupe de toute la chaîne nécessaire pour y arriver. L’interface, les règles métier, les données, les tests et la mise en production avancent ensemble.

Ce découpage demande de l’attention au début du projet. Il remplace une bonne partie des séances d’estimation qui reviendraient autrement chaque semaine. Une fois les limites et le résultat attendu clarifiés, les tickets partagent le même ordre de grandeur et peuvent être pris les uns après les autres.

#NoEstimates ne veut pas dire avancer sans prévision

Le nom prête parfois à confusion. Avec #NoEstimates, nous ne chiffrons pas chaque ticket séparément, mais nous continuons à donner de la visibilité sur le calendrier et le budget. Comme les tickets sont petits et comparables, nous pouvons nous appuyer sur leur nombre et sur le rythme auquel l’équipe les termine réellement.

Prenons un périmètre de 18 tickets. Si l’historique montre que l’équipe en livre habituellement 5 à 7 par semaine, une première prévision se situe entre trois et quatre semaines. La semaine suivante apporte de nouvelles données, et nous mettons la prévision à jour. Si quatre tickets sont ajoutés ou retirés, nous pouvons aussi en montrer l’effet sans refaire tout le chiffrage.

Au début, cette fourchette repose sur peu d’informations. Elle devient plus juste au fil du projet, parce qu’elle s’appuie sur un historique concret : les tickets que cette équipe a réellement livrés, dans ce produit et dans ses conditions de travail. Nous partageons cet historique avec le client et révisons ensemble la suite lorsque le périmètre évolue.

Voir le produit prendre forme

Une petite livraison est aussi plus facile à relire et à tester. Elle touche une partie limitée du produit, ce qui réduit le risque de régression. Si un défaut apparaît malgré tout, nous savons où chercher et pouvons intervenir rapidement.

Le changement le plus appréciable se trouve souvent dans les échanges. Dès qu’un ticket est terminé, le client peut voir le résultat et, lorsque c’est pertinent, le faire essayer aux utilisateurs. Parfois le retour confirme la direction choisie. Parfois il révèle un détail gênant ou une attente différente. Dans tous les cas, il arrive assez tôt pour être pris en compte dans les tickets suivants.

Le produit se construit ainsi sous les yeux du client, sans attendre une grande livraison finale. Les discussions partent de ce qui fonctionne déjà et des réactions recueillies. Il devient plus simple de décider ce qui mérite d’être développé ensuite, et ce qui peut attendre.

Et lorsqu’un sujet demande une estimation spécifique ?

Certains travaux se prêtent moins bien à ce fonctionnement. Une migration délicate, une dépendance externe ou une contrainte réglementaire peut demander une analyse et une estimation dédiées. #NoEstimates n’est pas une règle à appliquer sans discernement ; c’est une façon d’éviter le chiffrage détaillé lorsqu’un découpage fin et l’historique apportent déjà une réponse plus utile.

Chez Kairisio, nous utilisons cette approche pour garder une relation simple avec nos clients. Nous préparons les prochaines étapes ensemble, montrons régulièrement ce qui a été livré et ajustons la suite à partir de ce que nous observons. Si vous souhaitez voir comment cela pourrait s’appliquer à votre produit, nous pouvons commencer par en découper une première version avec vous.