Cessez de deviner les dates de livraison : prévoir à partir de vos propres données empiriques
Scrum se fonde sur l'empirisme : on inspecte ce qui s'est réellement passé et on s'adapte selon les faits, pas selon ses souhaits. La prévision est l'endroit où ce principe est mis à l'épreuve le plus directement. Une équipe qui prévoit bien gagne le droit qu'on lui confie l'ambiguïté; une équipe qui prévoit mal se fait microgérer. Le Guide Scrum laisse volontairement la méthode ouverte, une liberté que bien des équipes utilisent mal.
Au début de 2022, avec le roulement à l'embauche, les perturbations du retour au bureau et les dépendances liées à l'approvisionnement, la tentation de promettre une date nette est forte et le coût de la rupture de cette promesse est élevé. Une prévision n'est pas un engagement; c'est un énoncé probabiliste bâti à partir de vos données réelles. Faites bien cette distinction et le reste suit.
Là où les prévisions dérapent
Traiter les points d'effort comme une unité de temps. Les points estiment un effort relatif, pas des heures, et ils dérivent à mesure que l'équipe apprend. Convertir des points en dates avec un taux fixe fabrique une fausse précision. Le débit, soit le nombre d'éléments terminés par Sprint, est une base de prévision plus saine.
Prévoir à partir d'une seule moyenne. Dire que l'équipe livre environ dix éléments par Sprint masque une énorme variation. Un seul chiffre donne au mieux une prévision à pile ou face. Il vous faut la dispersion, pas seulement le milieu, pour dire quoi que ce soit d'honnête sur une date.
Utiliser trop peu d'historique. Une prévision bâtie sur deux ou trois Sprints hérite de tout leur bruit. Utilisez une fenêtre glissante de Sprints récents, assez pour capter la variation normale mais assez récente pour refléter l'équipe d'aujourd'hui, pas celle d'il y a un an.
Ignorer la croissance du périmètre. Les prévisions supposent un backlog figé, mais les vrais backlogs grossissent à mesure que le travail se découvre. Si vous ne tenez pas compte du rythme d'ajout d'éléments, vous prévoyez contre une cible qui recule sans cesse.
Communiquer une date comme une promesse. Une seule date ferme invite à la déception. Communiquer une fourchette avec des niveaux de confiance pose des attentes honnêtes et protège la crédibilité de l'équipe quand la réalité atterrit quelque part dans la fourchette.
Une approche pratique et empirique
Commencez par compter le débit par Sprint sur une fenêtre récente de, disons, six à dix Sprints. Regardez la distribution, pas seulement la moyenne. À partir de là, la prévision honnête la plus simple est une fourchette : dans ses semaines lentes l'équipe termine tant d'éléments, à son rythme habituel tant, dans ses bonnes semaines tant. Confrontez ces rythmes au backlog restant (et croissant) pour produire une date probable assortie d'une bande de confiance plutôt qu'un point unique.
Prévoyez en éléments terminés, à l'aide du débit, avant de recourir aux points.
Exprimez les résultats en fourchette avec confiance, jamais en date isolée.
Tenez compte de la croissance du backlog, pas seulement du travail visible aujourd'hui.
Rafraîchissez la prévision à chaque Sprint à mesure que les données arrivent, et laissez-la bouger.
Pour une modélisation plus riche, une simulation Monte-Carlo sur votre historique de débit transforme les mêmes données en probabilités.
Rien de tout cela n'exige un outil lourd; un tableur des éléments terminés par Sprint suffit pour commencer. La discipline est l'essentiel : prévoir à partir de ce que l'équipe a réellement fait, communiquer l'incertitude clairement et mettre à jour sans relâche. C'est l'empirisme appliqué à l'avenir, et c'est ce qui distingue une équipe en qui on a confiance d'une équipe qu'on remet en question.
Si vos équipes prévoient à l'espoir plutôt qu'au débit et que les parties prenantes ne croient plus aux dates, le conseil en exécution de programmes et de projets de XNM peut vous aider à bâtir des prévisions qui résistent à l'examen.