Terminer avec les estimations?

– Pourquoi votre équipe ne fait plus d’estimation ?

– Parce que nous n’en avons plus besoin.

– Les estimations ne sont-elles pas obligatoires en Scrum ?

– Non ce n’est pas obligé.

– OK, mais vous faites comment pour savoir combien d’items mettre dans le Sprint Backlog? On a besoin d’estimation pour ça, non?

– Pas nécessairement, ou sinon, une estimation très grossière, mais non capturée. Je t’explique.

Évidemment, si on pense encore que le but d’un Sprint, est de livrer le plus de fonctionnalités possible, alors on a une tendance à vouloir chiffrer la durée du travail et à remplir le Sprint Backlog à pleine capacité. Les estimations deviennent alors souvent des « exactimations » et on essaie de mettre autant de points que la vélocité prévue. 🙁 En vérité, on est en train de faire un mini-projet en mode classique. Ce n’est pas ça l’agilité.

La posture Scrum/Agile, est de se dire : « Ce n’est pas important de livrer tout ce que nous avons prévu dans le Sprint Backlog. L’important est d’atteindre l’objectif de Sprint et de livrer les fonctionnalités les plus pertinentes pour notre produit et pour nos utilisateur·trices. »

Le Sprint planning ne sert donc pas à gérer la capacité de production d’une équipe, mais bien à s’assurer qu’elle a une direction claire et partagée de ce que le produit a besoin. Le focus sur les estimations détourne la discussion vers la quantité de travail plutôt que sur la pertinence du travail.

Donc lors du Sprint planning, on suit grosso modo le modèle suivant :

• On commence par se donner un objectif de Sprint clair qui clarifie en quoi le travail à faire est pertinent
  • ex: À la fin du Sprint, nos auditrices et auditeurs payants seront en mesure de bénéficier de la recharge automatique de leur compte.

• On identifie les items du Product Backlog qui sont nécessaires pour rencontrer l’objectif.
  • On les découpe en plus petit possible tout en nous assurant qu’ils apportent toujours de la valeur.
  • On identifie les dépendances nécessaires.

• On fait également remonter toutes les autres considérations techniques et organisationnelles auxquelles on doit faire attention dans le Sprint. (bugs qu’on doit corriger, réunions, installations techniques …)

Et là un des trois cas suivants se présente :

• Ça semble jouer. Les developpeur·euses sont confiant·es qu’il y a assez de travail pour occuper le Sprint tout en gardant un rythme soutenable. Qu’il y a une bonne probabilité, donc pas un engagement à 100%, de tout faire.

• Il y a trop d’items. Alors soit on revoit l’objectif de Sprint à la baisse, soit on découpe encore certains items, et/ou on dé-priorise d’autres tâches.
  • ex: À la fin du Sprint, nos auditrices et nos auditeurs payants seront notifiés automatiquement qu’elles ou ils doivent recharger leur compte.

• Il y a encore de l’espace. On peut alors revoir l’objectif de Sprint à la hausse, ou en profiter pour ajouter des items supplémentaires que les parties prenantes attendent, ou encore payer de la dette technique. L’objectif de Sprint n’est pas obligé de prendre 100% du Sprint Backlog.

Et voilà, notre Sprint Backlog.

– Ok, mais il y a quand même une estimation afin d’identifier dans lequel des 3 cas nous sommes.

– Bien sûr, mais ce n’est pas le focus du débat dans le Sprint Planning

Une équipe qui maitrise bien sa capacité de travail, et qui sait découper va rapidement pouvoir estimer à l’oeil, grossièrement, ce qu’il est possible de faire comme travail dans un Sprint sans utiliser d’estimations chiffrées.

Ne pas oublier que : “c’est OK de ne pas être parfait” on cherche à être dans le “assez bon (Good enough)”.

En fait l’important est de trouver l’équilibre entre :

• détailler suffisamment de travail pour le Sprint afin de pouvoir avancer confortablement sans avoir à refaire un planning,
• et ne pas perdre de temps à détailler des choses si on est certain qu’on n’aura pas le temps de les faire.

Pour ça, le secret est dans le découpage. On découpe toujours le plus petit possible et ensuite, quand de toute manière on ne peut plus découper, alors il faut bien le faire.

Et oui, quand on fait la sélection des items à mettre dans le Sprint, il y a forcément un moment où on va se poser la question : “Est-ce que cet item est trop gros ou non pour entrer dans le Sprint ?”

Et c’est en effet un processus d’estimation, mais grossier. Quelque chose qui ressemble à :

A) Trop gros → on découpe

B) Assez petit → c’est bon, on prend

C) Ne sais pas → on prévoit une timebox pour faire de la recherche

Chaque équipe déterminera ce que veut dire « Assez petit » selon son contexte

• un exemple : On accepte un item dans le Sprint si on a confiance qu’on peut le faire en moins de 3 jours

Mais pas besoin de chiffrer l’item. Juste indiquer “Ready to Sprint”

– Voilà j’espère que tu comprends mieux quand on dit qu’on ne fait plus d’estimation. L’important c’est l’activité de découpage et d’estimation en « assez petit ». pas le chiffre qui en résulte.

---

En Scrum on peut estimer. Savoir pourquoi, pour qui et comment on estime sont les bonnes questions à se poser. C’est différent que de dire “En Scrum il faut estimer”.

Il y a d’autres raisons de vouloir faire des estimations et d’autre façon de répondre aux questions, par exemple pour les Product Owners afin de pouvoir faire des projections de livraison. Pour cela, je t’invite à jeter un oeil à « Professional Scrum with Kanban » afin de mettre en place des pratiques et des métriques qui permettront de faire des prévisions tout en évitant les estimations chiffrées.

Et si tu veux en savoir plus sur comment utiliser Scrum pour en faire un outil qui permet l’agilité plutôt que simplement « faire du Scrum », n’hésite pas à t’inscrire à une formation « Professional Scrum Master«