Prévoir sprint après sprint : utiliser vos propres données plutôt que des suppositions
Dix-huit mois après le début d'un monde bouleversé, bien des équipes se sont fait poser la même question gênante : quand est-ce que ce sera terminé? Les chaînes d'approvisionnement demeuraient peu fiables, la moitié de l'équipe travaillait depuis la table de la cuisine, et la vieille habitude de promettre une date fixe fondée sur un souhait avait mal vieilli. Scrum offre une meilleure réponse, et elle n'exige pas de boule de cristal. Elle exige que vous utilisiez réellement les données que votre équipe produit déjà.
Scrum repose sur l'empirisme : on prend des décisions à partir de ce qu'on observe, et non de ce qu'on a supposé au départ. La prévision n'est que ce principe appliqué à l'avenir. Plutôt que d'annoncer une date en espérant, vous mesurez la quantité de travail que votre équipe a véritablement terminée au cours des derniers sprints, puis vous projetez ce rythme vers l'avant, tout en étant honnête sur l'incertitude qui l'entoure.
Commencez par mesurer le débit, pas les promesses
Le chiffre le plus utile est aussi le plus simple : combien d'éléments du Backlog de Produit l'équipe a-t-elle réellement terminés, sprint après sprint? C'est le débit. Vous pouvez utiliser des points d'effort si votre équipe estime de façon constante, mais compter les éléments terminés fonctionne souvent tout aussi bien et évite bien des querelles. Tirez les données réelles des huit à douze derniers sprints. Ne les lissez pas, n'effacez pas les mauvais sprints et n'incluez pas les éléments « presque terminés » — la Définition de « Terminé » est binaire pour une bonne raison.
Ne comptez que les éléments ayant satisfait à la Définition de « Terminé » durant ce sprint.
Utilisez une fenêtre constante — huit à douze sprints récents reflètent la réalité actuelle sans remonter trop loin.
Gardez la dispersion visible : une équipe qui livre 4, 9, 6, 3, 8 vous dit quelque chose qu'une simple moyenne masque.
Transformez les données en fourchette, pas en date
Une fois que vous disposez d'un relevé sprint par sprint, la prévision devient de l'arithmétique additionnée d'humilité. Le résultat honnête n'est jamais une date unique; c'est une fourchette assortie d'un niveau de confiance.
Évaluez le travail restant. Comptez les éléments du Backlog de Produit encore nécessaires à l'objectif que vous prévoyez. Ordonnez le backlog pour que les éléments les plus importants soient inclus en premier.
Trouvez votre rythme réaliste. Prenez le débit des sprints récents. Une prévision pessimiste utilise vos sprints les plus lents; une prévision optimiste, vos sprints les plus rapides.
Divisez pour obtenir un nombre de sprints. Les éléments restants divisés par le débit donnent un nombre de sprints. En le faisant avec votre rythme lent et votre rythme rapide, vous obtenez une honnête fourchette « entre X et Y sprints ».
Reprévoyez à chaque sprint. De nouvelles données arrivent à chaque Revue de Sprint. Mettez la prévision à jour à ce moment — une prévision qui ne bouge jamais est ignorée, pas digne de confiance.
Faites de l'incertitude un atout, pas un aveu
Les parties prenantes sous pression veulent une date unique, et l'instinct est de leur en donner une pour paraître décidé. Résistez. Une prévision présentée comme « le plus probable six sprints, possiblement jusqu'à neuf si les risques d'intégration se concrétisent » est bien plus utile — et plus crédible — qu'un assuré « 24 mars » que tout le monde sait en privé être une fiction. Si les années de pandémie nous ont appris quelque chose, c'est que la variabilité est réelle et que prétendre le contraire ne fait que reporter la déception. Communiquez la fourchette, nommez les hypothèses derrière l'extrémité optimiste, et laissez le Product Owner faire ses arbitrages en toute connaissance de cause.
Une mise en garde : la prévision empirique ne fonctionne que si vos sprints sont de vrais sprints. Si le « Terminé » glisse sans cesse, si le travail déborde des limites de sprint ou si l'équipe est interrompue constamment, vos données de débit sont du bruit et votre prévision en hérite. Réglez d'abord la discipline de livraison; la prévision suivra.
Instaurer une habitude de prévision à laquelle les parties prenantes font réellement confiance demande plus qu'un tableur — cela exige de la discipline de livraison et une gouvernance claire. le conseil en exécution de programmes et de projets de XNM aide les équipes à mettre les deux en place.