Une planification de sprint qui se termine vraiment à temps : deux équipes, deux résultats
Le Guide Scrum confie à la planification de sprint trois questions : pourquoi ce sprint a-t-il de la valeur, que peut-on accomplir, et comment le travail sera-t-il réalisé. Assez simple. Pourtant, deux équipes appliquant le même cadre peuvent terminer un sprint à des points complètement différents — l'une avec un incrément fonctionnel et un objectif de sprint atteint, l'autre avec des tickets à moitié faits qui glissent à la fois suivante. La différence vient rarement du cadre. Elle tient à la façon dont l'équipe utilise l'événement de planification. Imaginez deux équipes, huit personnes chacune, toutes deux sortant d'un 2022 marqué par les ratés d'approvisionnement et un rythme mi-télétravail, mi-bureau après le retour au présentiel.
L'équipe qui déborde
L'équipe A traite la planification comme une cérémonie de remplissage de file d'attente. Le schéma est connu, et il garantit en douce le débordement dont elle se plaint toutes les deux semaines.
Il n'y a pas d'objectif de sprint, juste une liste. Sans objectif, rien ne peut être retranché sous pression, car chaque élément semble également obligatoire.
Le backlog produit arrive non raffiné : la planification sert à décoder les exigences au lieu de décider du périmètre.
La capacité est ignorée. L'équipe prend le même nombre d'éléments qu'au sprint précédent alors que deux personnes sont en congé et une à moitié affectée au support.
Le « terminé » est flou. Personne ne confirme ce que finir veut dire, si bien que tests et revue sont découverts tard et reportés au sprint suivant.
Les dépendances — une pièce d'un fournisseur, une approbation externe — sont remarquées en plein sprint plutôt que mises au jour pendant que le plan est encore malléable.
L'équipe A est occupée tout le sprint et rate quand même. Elle confond activité et progrès, et faute d'objectif, il n'y a rien à refuser quand la réalité s'invite.
L'équipe qui réussit le sprint
L'équipe B traite la planification comme une prévision qu'elle compte honorer. Elle tient le même événement, dans la même heure, mais avec des habitudes plus affûtées.
Fixez d'abord l'objectif de sprint. Le Product Owner apporte un objectif unique et concret que l'incrément doit atteindre. L'objectif devient le filtre de décision : tout ce qui ne le sert pas devient candidat au report.
Planifiez selon la capacité réelle, pas le compte du dernier sprint. Retranchez les congés, la rotation de support, les réunions. Les Developers ne prennent que ce qu'ils croient sincèrement pouvoir terminer, et ce sont eux qui décident — la sélection leur revient, pas au Product Owner.
Raffinez juste assez avant, pas pendant. Grâce au raffinement continu, les premiers éléments du backlog sont déjà petits, clairs et estimés grossièrement ; la planification porte sur l'engagement, non sur la découverte.
Décomposez en un vrai plan pour les premiers jours. L'équipe découpe les principaux éléments en tâches qu'elle peut entamer aussitôt. Inutile d'avoir tous les détails de tout le sprint, mais les premiers jours sont concrets.
Appliquez la Definition of Done à chaque élément. Tests, revue et intégration font partie de l'estimation, pas d'arrière-pensées. Un élément n'est « pris » que si l'équipe pense pouvoir le rendre réellement terminé, pas seulement codé.
Quand quelque chose dérape en plein sprint — une pièce en retard, une dépendance bloquée — l'équipe B renégocie le périmètre par rapport à l'objectif de sprint avec le Product Owner et livre malgré tout quelque chose de valeur. L'équipe A se contente de reporter le travail inachevé et appelle cela de la vélocité. Le cadre était identique ; la discipline, non. Si vos sprints débordent régulièrement, la solution n'est généralement pas de travailler plus fort pendant le sprint — c'est de planifier une prévision que vous pouvez réellement assumer, ancrée à un objectif que vous êtes prêt à protéger.
Si vos sprints débordent sans cesse et que vous voulez une planification qui tienne, le conseil de XNM en réalisation de programmes et de projets peut aider vos équipes à planifier vers un objectif et à le livrer.