Quand le sprint a dépassé l'équipe : une histoire de planification de la capacité
Une équipe de services municipaux — appelons-la l'escouade des Permis — est venue nous voir, frustrée, à la fin de 2021. Elle avait adopté Scrum dix-huit mois plus tôt, la moitié de l'équipe travaillait désormais à distance, et chaque sprint se terminait de la même façon : une pile de travail inachevé reportée au sprint suivant. Les graphiques de vélocité semblaient chargés, mais la livraison stagnait. Le Scrum Master soupçonnait simplement une équipe lente. Les données racontaient autre chose.
Ce qui manquait réellement, c'était une planification honnête de la capacité. Le Guide Scrum ne prescrit pas de formule, mais la planification de sprint demande explicitement aux développeurs de prévoir ce qu'ils peuvent terminer de façon réaliste. Cette équipe prévoyait sur la base de l'espoir. En décortiquant ses six derniers sprints, on a vu une équipe qui s'engageait régulièrement sur environ 40 points et en terminait à peu près 28. L'écart n'était pas une question d'effort, mais d'arithmétique que personne n'avait faite.
Où passaient vraiment les heures
Nous avons fait un calcul simple pour un seul développeur sur un sprint de deux semaines. Dix jours ouvrables ne signifient pas dix jours de travail de sprint. Une fois soustraits les réunions, la rotation de soutien et le simple fait que les gens ne sont pas des machines, le vrai chiffre est bien plus petit — et en mode hybride, le coût de coordination augmente, il ne diminue pas.
Partez des jours disponibles, pas de l'effectif. Deux développeurs sur six étaient en vacances et un jour férié tombait dans le sprint. Cela retirait à lui seul près de 15 % du temps nominal avant même de commencer.
Soustrayez les cérémonies et les engagements récurrents. Mêlée quotidienne, planification, revue, rétrospective, plus un appel récurrent avec les parties prenantes : environ une journée par personne sur le sprint.
Réservez pour les interruptions que vous savez à venir. Un développeur était de garde en production cette semaine-là. Faire comme si ce temps était pleinement disponible était la principale source de reports.
Appliquez un facteur de concentration, honnêtement. Un développeur réaliste consacre 60 à 70 % de ses heures nominales au sprint, pas 100. Le changement de contexte à distance rapprochait cette équipe du bas de la fourchette.
En reconstruisant le sprint sur ces chiffres, la capacité réelle de l'équipe se situait autour de 28 points — exactement ce qu'elle terminait. Elle n'était pas lente. Elle planifiait un sprint qui n'existait pas.
Ce que nous avons changé pour le sprint suivant
Planifier selon la capacité démontrée (la vraie moyenne terminée), avec une petite marge plutôt qu'une cible ambitieuse.
Rendre la rotation de soutien visible et soustraite lors de la planification, au lieu d'une taxe invisible.
Définir le « terminé » de façon stricte pour qu'un élément fini soit réellement livrable, éliminant les reprises cachées déguisées en nouveau travail.
Revoir la capacité à chaque planification, car la disponibilité d'une équipe hybride change d'une semaine à l'autre.
Le résultat n'a rien eu d'héroïque. Au cours des trois sprints suivants, l'équipe s'est engagée à moins et a presque tout terminé. La prévisibilité est revenue, la pile de reports a presque disparu et — ce que le Scrum Master n'attendait pas — le moral est remonté. Les gens ont cessé de finir chaque sprint en se sentant en retard. La planification de la capacité ne les a pas rendus plus rapides ; elle a aligné leur plan sur la réalité, la seule prévision à laquelle une partie prenante peut vraiment se fier.
La leçon dépasse largement une seule équipe. Un engagement de sprint est une prévision, et une prévision fondée sur l'effectif nominal plutôt que sur des heures disponibles et concentrées échoue dès le contact avec un calendrier normal. Surtout pour des équipes distribuées qui s'installent encore dans le travail hybride, la discipline consiste à compter ce que l'on a vraiment avant de promettre ce que l'on livrera.
Si vos équipes de livraison s'engagent trop et terminent trop peu, le service-conseil en réalisation de programmes et de projets de XNM peut vous aider à ancrer la planification de sprint dans la capacité réelle et à rétablir une livraison prévisible.