L'une des erreurs les plus dommageables commises lors du Sprint Planning consiste à engager un volume de Story Points basé uniquement sur la vélocité historique moyenne, sans vérifier la capacité de travail réelle disponible sur les deux semaines à venir. Congés payés, jours fériés, formations techniques, astreintes et support de production : la disponibilité d'une équipe varie à chaque itération. Le Capacity Planning agile fournit la méthodologie mathématique indispensable pour éviter le sur-engagement chronique.
Capacité théorique vs Capacité réelle : la distinction fondamentale
Pour planifier sereinement un sprint, il convient de différencier deux notions souvent confondues :
- La Vélocité historique : Le nombre moyen de Story Points livrés par l'équipe sur les 3 à 5 derniers sprints.
- La Capacité nette disponible : Le nombre réel d'heures ou de jours-hommes de développement effectif disponibles sur le sprint à venir.
Règle d'or de la planification agile : La vélocité historique sert de référence générale, mais c'est la capacité nette disponible qui fixe la limite maximale d'engagement du sprint en cours.
Guide de calcul pas à pas de la capacité disponible
Le calcul de la capacité s'effectue en jours-hommes (ou en heures) en suivant trois étapes simples :
Étape 1 : Calculer le total des jours bruts théoriques de l'équipe
Pour une équipe de 5 développeurs sur un sprint de 10 jours ouvrés, le potentiel brut est de :
5 personnes x 10 jours = 50 jours-hommes
Étape 2 : Déduire l'ensemble des absences et indisponibilités planifiées
- Un développeur pose 3 jours de congés payés : -3 jours.
- Un jour férié intervient pendant le sprint pour l'ensemble de l'équipe : -5 jours.
- Un membre participe à une formation sécurité de 2 jours : -2 jours.
Capacité brute disponible = 50 - 3 - 5 - 2 = 40 jours-hommes.
Étape 3 : Appliquer le Focus Factor (Coefficient de focalisation)
Aucun ingénieur ne produit du code 8 heures par jour de façon ininterrompue. Les cérémonies Scrum (Daily, Affinage, Démo, Rétro), la gestion des emails, le support de production N3 et les échanges informels consomment une partie du temps. Le Focus Factor moyen d'une équipe Scrum mature se situe entre 0.65 et 0.80 (soit 65% à 80% du temps dédié exclusivement aux User Stories).
Capacité nette effective = 40 jours bruts x 0.70 (Focus Factor) = 28 jours-hommes de travail effectif.
Convertir la capacité nette en engagement de Story Points
Une fois la capacité nette calculée, il reste à la convertir en engagement de Story Points grâce au ratio historique de l'équipe :
| Métrique de planification | Historique de référence | Calcul du Sprint à venir |
|---|---|---|
| Capacité nette habituelle | 35 jours-hommes | 28 jours-hommes (Sprint avec absences) |
| Vélocité moyenne livrée | 40 Story Points | --- |
| Ratio de productivité | 40 pts / 35 j = 1.14 pt/jour | --- |
| Engagement cible ajusté | --- | 28 j x 1.14 = 32 Story Points |
Grâce à cet ajustement méthodique, l'équipe s'engage sur 32 Story Points au lieu des 40 points habituels, évitant ainsi un échec de sprint quasi certain lié aux congés et au jour férié.
Les 4 meilleures pratiques pour préserver la capacité d'équipe
- Ne jamais planifier à 100% de la capacité nette : Conservez un buffer d'urgence d'au moins 10% à 15% pour absorber les anomalies critiques de production sans faire échouer l'objectif de sprint.
- Re-évaluer le Focus Factor en rétrospective : Si l'équipe rapporte un excès de réunions parasites, réduisez temporairement le Focus Factor à 0.60 lors de la planification suivante.
- Ne pas modifier l'estimation des Story Points : La valeur d'effort d'une User Story reste constante. On adapte le nombre de tickets engagés dans le sprint, jamais la cotation des stories.
- Maintenir une vue centralisée des disponibilités : Dans l'outil Manifst Gestion d'Équipe, la capacité disponible et le calendrier des membres sont synchronisés automatiquement avec les tableaux de sprint.
Essayer Manifst gratuitement : gestion de la capacité et planification de sprint intégrées →