Modèle d'agenda de planification de sprint pour les équipes d'ingénierie
Pourquoi les sprints sont surchargés
La planification de sprint a un échec structurel que les modèles ne préviennent pas : les équipes sélectionnent le backlog de sprint avant que quiconque vérifie la capacité. Le résultat est un sprint qui semblait réalisable sur un tableau blanc et s'effondre le mercredi quand deux ingénieurs sont absents la moitié de la semaine, un ticket triple de périmètre, et trois éléments avaient des dépendances non déclarées sur un service que l'équipe plateforme est en train de réécrire.
La solution est simple et presque jamais appliquée : s'engager sur la capacité avant de s'engager sur le travail. Le modèle ci-dessous ouvre sur une revue de capacité exactement pour cette raison.
L'agenda (à copier-coller)
Durée : 2 heures pour un sprint de 2 semaines ; 1 heure pour un sprint d'une semaine
Format : Animé, avec le backlog visible pour toute l'équipe
Section 1 — Objectif du sprint (10 min)
- Une phrase : à quoi ressemble un sprint réussi vu de l'extérieur ?
- L'objectif doit être suffisamment précis pour que n'importe quel membre de l'équipe puisse évaluer en fin de sprint si on l'a atteint
- Rejeter les objectifs qui ne sont qu'une liste de tickets (« finir le refactoring d'auth et la page de facturation ») — c'est un backlog, pas un objectif
Section 2 — Revue de capacité (15 min)
- Lister chaque membre de l'équipe par nom
- Pour chacun : congés prévus, rotation d'astreinte, réunions récurrentes, engagements externes connus
- Exprimer la capacité en story points disponibles ou en jours — pas en nombre de personnes
- Ce chiffre est le plafond ; ne pas sélectionner plus de travail qu'il ne le permet
Section 3 — Sélection du backlog (45 min)
- Parcourir les éléments les plus prioritaires du backlog affiné
- Pour chaque candidat : l'équipe a-t-elle assez pour le démarrer, ou y a-t-il des questions ouvertes qui nécessitent des réponses avant le début du sprint ? Les questions ouvertes appartiennent à la file d'affinage, pas au sprint
- Arrêter la sélection à 80 % de la capacité ; les 20 % restants absorbent les reports et le travail non planifié
Section 4 — Critères d'acceptation (20 min)
- Pour chaque élément sélectionné : énoncer le critère qui le considère comme terminé
- Si l'équipe ne peut pas énoncer un critère en 60 secondes, le ticket n'est pas assez affiné — le renvoyer au backlog
- L'écrire dans le ticket maintenant, en séance ; ne pas compter sur « on l'ajoutera plus tard »
Section 5 — Risques et dépendances (15 min)
- Qu'est-ce qui pourrait bloquer la livraison de l'objectif du sprint et que l'équipe ne contrôle pas ?
- Nommer le responsable de la dépendance ; le faire remonter maintenant pendant qu'il est encore temps de le résoudre avant le milieu du sprint
- Les dépendances non résolues obtiennent un responsable nommé au sein de l'équipe qui les suivra
Clôture (15 min)
- Confirmer que l'objectif du sprint est toujours valide au vu du travail sélectionné
- Désigner le rédacteur du récapitulatif de sprint, ou confirmer la configuration du rapport automatisé
- Confirmer la prochaine date de planification
Ce que la plupart des modèles de planification de sprint ratent
Les modèles de planification de sprint les plus populaires se concentrent sur l'affinage du backlog et la définition de « terminé ». Les deux sont importants. Aucun ne traite l'erreur de planification qui produit le plus d'échecs de sprint : sélectionner le travail sans vérifier la disponibilité.
Une équipe de cinq ingénieurs à pleine capacité a environ 200 story points disponibles par sprint de 2 semaines. Une équipe de cinq avec deux ingénieurs en congé, un en astreinte rotative, et un à un séminaire de trois jours en a peut-être 110. Si vous sélectionnez 180 points dans le second sprint, vous avez déjà échoué. La sélection est là où le surengagement se produit, et la capacité doit la précéder.
Le second écart est celui des critères d'acceptation. Les équipes avancent vite en planification et ont l'intention d'écrire les critères plus tard. Plus tard ne se passe pas avec le même niveau de précision. La personne qui aurait écrit un critère précis en séance écrit quelque chose de plus vague de mémoire le lendemain, ou ne l'écrit pas du tout. Les désaccords en cours de sprint sur ce que « terminé » signifie sont presque toujours traçables à des critères d'acceptation sautés en planification.
Le coût cumulé de ces lacunes — sprints surchargés, découvertes en cours de sprint, définitions remises en question — apparaît clairement quand on l'additionne : La taxe des réunions.
Pourquoi les notes de planification de sprint sont plus difficiles qu'elles n'y paraissent
La planification de sprint génère plus d'informations que presque toute autre réunion récurrente : l'objectif du sprint, les chiffres de capacité, la logique de sélection élément par élément, les critères d'acceptation par ticket, les responsables de dépendances, les points de risque. Rédiger un récapitulatif utile requiert de tout capturer sous une forme utilisable trois jours plus tard quand quelqu'un demande « pourquoi a-t-on coupé cet élément ? »
Pavleur génère automatiquement le rapport de planification de sprint à la fin de l'appel. Il capture l'objectif du sprint, le backlog sélectionné avec sa logique, les critères d'acceptation tels qu'énoncés en réunion, et les responsables de dépendances tels que nommés. Si quelqu'un a partagé son écran avec le backlog ou le tableau de capacité, ce visuel est inclus dans le rapport avec la discussion — contexte que des outils audio seuls comme Otter ou Fireflies rateraient entièrement. Toute personne ayant rejoint tardivement ou ayant besoin de vérifier une décision en cours de sprint dispose du dossier complet. Pour une comparaison de la différence avec les outils audio seuls : Pavleur face aux alternatives.
Gérer le changement de plan en cours de sprint
Le plan de sprint est un engagement, pas un contrat. Quand quelque chose en cours de sprint invalide genuinement le plan — un incident en production, une dépendance critique bloquant trois tickets, un changement de priorité venant de la direction — la bonne réponse est un appel de re-planification rapide, pas une réduction de périmètre silencieuse. L'appel de re-planification prend 20 minutes et produit un objectif de sprint mis à jour qui reflète la réalité. L'alternative est un sprint qui échoue sur le papier mais s'est ajusté de manière informelle sans que personne ne l'ait écrit, rendant la rétrospective plus difficile et les chiffres de vélocité sans signification.
Cultivez l'habitude de la re-planification explicite. Utilisez la même structure : capacité mise à jour, sélection révisée, objectif ré-énoncé. Cela prend bien moins de temps que la confusion qu'on prévient.