6 min lecture • Guide 192 of 877
Améliorer la Précision du Sprint Planning
La précision du sprint planning détermine si vous livrez ce que vous avez engagé ou ratez constamment les objectifs. Une planification précise construit la confiance avec les parties prenantes, permet des prévisions fiables et crée un rythme soutenable. Cela nécessite des données, de la discipline et une calibration continue.
Problèmes de Précision
| Problème | Cause | Solution |
|---|---|---|
| Sur-engagement | Biais d'optimisme | Utiliser vélocité historique |
| Travail non terminé | Scope creep | Protéger l'engagement |
| Surprises constantes | Travail inconnu | Ajouter un buffer |
| Estimations imprécises | Pas de boucle feedback | Suivre réel vs estimé |
Amélioration de l'Estimation
Utiliser les Données Historiques
PLANIFICATION BASÉE SUR LA VÉLOCITÉ:
════════════════════════════════════
VÉLOCITÉ HISTORIQUE:
─────────────────────────────────────
Sprint Engagé Complété Taux
────────────────────────────────────
20 35 32 91%
21 38 29 76%
22 32 30 94%
23 34 33 97%
24 36 31 86%
25 33 32 97%
─────────────────────────────────────
Vélocité moyenne: 31 points
Écart-type: 1.5 points
Capacité fiable: 30 points (moy - 1 std)
PLANIFICATION PROCHAIN SPRINT:
├── Ne pas engager > 30 points
├── Si éléments incertains, engager moins
├── Laisser de la place pour les surprises
└── 30 points = engagement réaliste
TENDANCE DE VÉLOCITÉ:
├── Stable: Utiliser la moyenne
├── En amélioration: Utiliser moyenne récente (3 derniers)
├── En déclin: Investiguer la cause
└── Erratique: Utiliser le plus bas récent
Décomposition des Tâches
DÉCOUPER LE TRAVAIL:
════════════════════
AVANT:
─────────────────────────────────────
User Story: "Connexion utilisateur"
Estimation: 13 points (grande, vague)
Précision: Faible (trop gros pour estimer)
APRÈS (décomposé):
─────────────────────────────────────
Sous-tâches:
├── 1. Formulaire de connexion UI 2 pts
├── 2. Endpoint d'authentification 3 pts
├── 3. Gestion de session 3 pts
├── 4. Récupération mot de passe 2 pts
└── 5. Tests E2E 2 pts
─────────────────────────────────────
Total: 12 points (plus précis, plus petit)
Chaque tâche: Complétable en 1-2 jours
Gestion de la Capacité
Calculer la Capacité Réelle
CAPACITÉ RÉELLE VS THÉORIQUE:
═════════════════════════════
CALCUL DE CAPACITÉ:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ÉQUIPE: 5 développeurs │
│ JOURS DANS LE SPRINT: 10 │
│ │
│ CAPACITÉ THÉORIQUE: │
│ 5 développeurs × 10 jours × 8h = 400 heures │
│ │
│ DÉDUCTIONS: │
│ ├── Réunions (planning, standup, retro): 15% = -60h │
│ ├── Vacances/absences planifiées: 10% = -40h │
│ ├── Support/incidents: 10% = -40h │
│ ├── Revues de code: 10% = -40h │
│ └── Buffer imprévus: 10% = -40h │
│ │
│ CAPACITÉ RÉELLE: 400 - 220 = 180 heures │
│ EN POINTS (5h/point): 180 / 5 = 36 points │
│ │
│ AVEC MARGE DE SÉCURITÉ (10%): 32 points │
└─────────────────────────────────────────────────────────────┘
Facteur de Focus
FACTEUR DE FOCUS PAR ÉQUIPE:
════════════════════════════
DÉFINITION:
Facteur de Focus = Points Complétés / Capacité Théorique
EXEMPLE:
├── Capacité théorique: 50 points
├── Points complétés moyens: 35 points
├── Facteur de focus: 70%
└── Pour planifier: 50 × 0.70 = 35 points
FACTEURS TYPIQUES:
┌─────────────────────────────────────────────────────────────┐
│ Type d'Équipe │ Facteur │ Notes │
├─────────────────────────────────────────────────────────────┤
│ Équipe stable, peu support│ 80% │ Optimal │
│ Équipe avec support │ 65-70% │ Normal │
│ Nouvelle équipe │ 50-60% │ En formation │
│ Équipe avec tech debt │ 55-65% │ Refactoring │
│ Équipe avec onboarding │ 60% │ Mentorat │
└─────────────────────────────────────────────────────────────┘
Protéger le Scope
Éviter le Scope Creep
PROTECTION DU SCOPE ENGAGÉ:
═══════════════════════════
RÈGLES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. ENGAGEMENT = CONTRAT │
│ Le scope engagé au planning est protégé │
│ Pas d'ajouts sans retrait équivalent │
│ │
│ 2. NOUVELLE DEMANDE = NÉGOCIATION │
│ Si urgent: Quoi retire-t-on? │
│ Si pas urgent: Backlog pour prochain sprint │
│ │
│ 3. VISIBILITÉ DES CHANGEMENTS │
│ Tracker tout ajout en cours de sprint │
│ Mesurer l'impact sur l'engagement │
│ │
│ 4. BUFFER PLANIFIÉ │
│ 10-15% de la capacité non engagée │
│ Pour les vraies urgences uniquement │
│ │
└─────────────────────────────────────────────────────────────┘
DIALOGUE D'EXEMPLE:
─────────────────────────────────────
Stakeholder: "Peut-on ajouter cette feature urgente?"
Équipe: "Bien sûr. Pour l'ajouter, nous devons retirer
soit A (3 pts) soit B (2 pts). Préférence?"
Stakeholder: "Retirez B, c'est moins critique."
Résultat: Scope protégé, engagement maintenu
Métriques de Précision
Tableau de Bord
MÉTRIQUES DE SPRINT PLANNING:
═════════════════════════════
TAUX DE COMPLÉTION:
┌─────────────────────────────────────────────────────────────┐
│ Sprint │ Engagé │ Complété │ Taux │ Statut │
├─────────────────────────────────────────────────────────────┤
│ S20 │ 35 │ 32 │ 91% │ ✅ En cible │
│ S21 │ 38 │ 29 │ 76% │ ⚠️ Sous-performance│
│ S22 │ 32 │ 30 │ 94% │ ✅ En cible │
│ S23 │ 34 │ 33 │ 97% │ ✅ Excellent │
│ S24 │ 36 │ 31 │ 86% │ ✅ En cible │
└─────────────────────────────────────────────────────────────┘
ZONES CIBLES:
├── 🔴 < 70%: Problème de planification
├── 🟡 70-80%: Amélioration nécessaire
├── 🟢 80-90%: Zone optimale
├── 🔵 > 95%: Possible sous-engagement
└── Cible: 80-90% stable
ANALYSE S21 (76%):
├── Cause: Intégration API externe retardée
├── Impact: 9 points non livrés
├── Action: Ajouter buffer pour dépendances externes
└── Résultat: S22-S24 améliorés
GitScrum pour la Planification
Outils de Planification
FONCTIONNALITÉS GITSCRUM:
═════════════════════════
PLANNING ASSISTÉ:
┌─────────────────────────────────────────────────────────────┐
│ SPRINT 26 - PLANIFICATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ CAPACITÉ SUGGÉRÉE: 32 points │
│ Basé sur: Vélocité 6 derniers sprints │
│ Absences prévues: Alice (2 jours) │
│ │
│ ACTUELLEMENT SÉLECTIONNÉ: 35 points ⚠️ │
│ Avertissement: Dépasse capacité de 3 points │
│ │
│ RECOMMANDATIONS: │
│ ├── Retirer 1 item de 3+ points │
│ ├── Ou marquer 3 pts comme "stretch goal" │
│ └── US-234 similaire à US-189 (dépassement +50%) │
│ │
│ RISQUES IDENTIFIÉS: │
│ ├── US-245: Dépendance externe (API partenaire) │
│ └── US-251: Non estimé par l'équipe complète │
└─────────────────────────────────────────────────────────────┘