Créer des Backlogs de Sprint Efficaces

Un backlog de sprint trop ambitieux mène à l'échec et à la démoralisation. Un qui est trop léger gaspille la capacité. Créer des backlogs de sprint efficaces signifie sélectionner la bonne quantité du bon travail, correctement préparé et compris par l'équipe.

Problèmes de Backlog de Sprint

Préparation du Backlog

Définition de Prêt

DÉFINITION DE PRÊT (DoR)
════════════════════════

Une tâche est PRÊTE pour le sprint quand:

CLARTÉ:
- [ ] Description claire et complète
- [ ] Critères d'acceptation définis
- [ ] Le "pourquoi" est compris (contexte/valeur)
- [ ] Questions ont été répondues

TAILLE:
- [ ] Estimée par l'équipe
- [ ] Peut être complétée dans le sprint
- [ ] Idéalement 1-3 jours de travail
- [ ] Éléments plus grands sont découpés

DÉPENDANCES:
- [ ] Pas de dépendances bloquantes
- [ ] Dépendances externes identifiées
- [ ] Prérequis complets ou planifiés

RESSOURCES:
- [ ] Design/maquettes disponibles (si nécessaire)
- [ ] Spécifications API disponibles (si nécessaire)
- [ ] Données de test/environnements prêts
- [ ] Compétences existent dans l'équipe

Prêt vs Non Prêt

PRÊT VS NON PRÊT
════════════════

✓ PRÊT:
"Implémenter flux de réinitialisation mot de passe"
- Endpoint API documenté
- Template email approuvé  
- Critères d'acceptation: 5 éléments spécifiques
- Estimation: 5 points
- Pas de blocages

✗ NON PRÊT:
"Construire authentification utilisateur"
- Trop vague - quelle méthode d'auth?
- Pas de specs API
- Pas de critères d'acceptation
- Pas d'estimation
- Dépend de travail non terminé

Processus de Planification de Sprint

Calcul de Capacité

CALCUL DE CAPACITÉ
══════════════════

ÉTAPE 1: Calculer les Jours Disponibles
─────────────────────────────────────
Durée du sprint:      10 jours (2 semaines)
Membres équipe:       5 développeurs
Total jours-personne: 50 jours

ÉTAPE 2: Soustraire Indisponibilités
─────────────────────────────────────
Congés:               -3 jours (@sarah, @mike)
Jours fériés:         -0 jours
Formation:            -2 jours (@lisa)
────────────────────────────
Disponible:           45 jours-personne

ÉTAPE 3: Tenir Compte du Non-Codage
─────────────────────────────────────
Réunions (~15%):      -6,75 jours
Support/bugs (~10%):  -4,5 jours
────────────────────────────
Capacité:             33,75 jours

ÉTAPE 4: Convertir en Story Points
─────────────────────────────────────
Si 1 point ≈ 0,5 jour travail idéal
Capacité ≈ 67 story points

ÉTAPE 5: Appliquer Facteur Historique
─────────────────────────────────────
Vélocité moyenne:     52 points
3 derniers sprints:   48, 55, 53

→ Cible ce sprint: 50-55 points
  (conservateur vu les congés)

Réunion de Planification de Sprint

STRUCTURE PLANIFICATION DE SPRINT
═════════════════════════════════

DURÉE: 2-4 heures (pour sprint de 2 semaines)

PARTIE 1: QUOI (60 min)
─────────────────────────────────────
Le product owner présente:
├── Objectif du sprint
├── Priorités principales du backlog
└── Contexte métier

L'équipe confirme:
├── Compréhension du travail
├── Questions répondues
└── Le travail est "prêt"

PARTIE 2: COMBIEN (45 min)
─────────────────────────────────────
Calculer la capacité:
├── Disponibilité de l'équipe
├── Engagements connus
└── Marge pour imprévus

Tirer du backlog:
├── Plus haute priorité d'abord
├── Jusqu'à atteindre capacité
└── Laisser 10-15% marge

PARTIE 3: COMMENT (45+ min)
─────────────────────────────────────
Pour chaque élément:
├── Découper en sous-tâches
├── Identifier dépendances
├── Assigner propriétaires initiaux
└── Noter risques/préoccupations

RÉSULTAT:
├── Backlog de sprint engagé
├── Objectif de sprint clair
├── Assignations initiales
└── Risques documentés

Structure du Backlog dans GitScrum

Vue du Backlog de Sprint

VUE BACKLOG DE SPRINT
═════════════════════

┌─────────────────────────────────────────────────────────┐
│  Sprint 23: Authentification Utilisateur               │
│  18-29 Mar | Objectif: Compléter flux auth pour mobile │
├─────────────────────────────────────────────────────────┤
│  Capacité: 52 pts | Engagé: 48 pts | Marge: 8%         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  À FAIRE (32 pts)     EN COURS         FAIT            │
│  ────────────         ────────         ────            │
│                                                         │
│  ┌────────────────┐   ┌──────────┐                     │
│  │ API Login      │   │ Réinit.  │                     │
│  │ 8 pts @mike    │   │ MDP      │                     │
│  │ Prêt ✓         │   │ 5 pts    │                     │
│  └────────────────┘   │ @sarah   │                     │
│                       └──────────┘                     │
│  ┌────────────────┐                                    │
│  │ Setup OAuth    │                                    │
│  │ 5 pts @lisa    │                                    │
│  │ Prêt ✓         │                                    │
│  └────────────────┘                                    │
│                                                         │
│  ┌────────────────┐                                    │
│  │ UI Login Mobile│                                    │
│  │ 8 pts @tom     │                                    │
│  │ Bloqué: API    │                                    │
│  └────────────────┘                                    │
│                                                         │
│  ... plus d'éléments ...                               │
│                                                         │
└─────────────────────────────────────────────────────────┘

Découpage des Tâches

EXEMPLE DE DÉCOUPAGE DE TÂCHE
═════════════════════════════

STORY: Implémentation API Login (8 pts)

SOUS-TÂCHES:
├── Créer endpoint login (2 pts)
│   └── @mike, Jour 1-2
├── Implémenter génération JWT (2 pts)
│   └── @mike, Jour 2-3
├── Ajouter limitation de taux (1 pt)
│   └── @mike, Jour 3
├── Écrire tests unitaires (2 pts)
│   └── @mike, Jour 4
└── Mettre à jour documentation API (1 pt)
    └── @mike, Jour 4-5

DÉPENDANCES:
├── Nécessite: Modèle utilisateur (complet ✓)
├── Nécessite: Bibliothèque JWT (complet ✓)
└── Bloque: UI login mobile

CRITÈRES D'ACCEPTATION:
├── POST /api/login accepte email/mot de passe
├── Retourne JWT en cas de succès
├── Retourne 401 si identifiants invalides
├── Limité à 5 tentatives/minute
├── Enregistré dans piste d'audit
└── Tests couvrent tous les scénarios

Gérer le Backlog de Sprint

Pendant le Sprint

GESTION DU BACKLOG DE SPRINT
════════════════════════════

VÉRIFICATIONS QUOTIDIENNES:
├── Des éléments bloqués?
├── Éléments prenant plus longtemps que prévu?
├── Du scope creep en cours?
├── Toujours en bonne voie pour l'objectif de sprint?

AJUSTEMENTS MI-SPRINT:
├── Pouvons-nous concentrer efforts sur blocages?
├── Besoin de réduire le scope?
├── Peut-on ajouter du travail si en avance?
└── Communiquer les changements

CHANGEMENTS DE SCOPE:
Si nouveau travail urgent apparaît:
1. Évaluer urgence vs. travail actuel
2. Si vraiment urgent, quoi retirer?
3. Discuter avec product owner
4. Documenter le changement
5. Communiquer aux parties prenantes

JAMAIS:
├── Ajouter silencieusement du travail
├── Laisser le scope creep arriver
├── Rater l'objectif de sprint sans alerter tôt
└── Blâmer l'équipe pour facteurs externes

Suivi du Burndown

BURNDOWN DE SPRINT
══════════════════

Points restants par jour:

48 │●
   │  ●
40 │    ●  ● (retard)
   │         ●
32 │           ●
   │             ●
24 │               ●
   │                 ●
16 │                   ●
   │                     ●
 8 │                       ●
   │                         ●
 0 │──────────────────────────●
   J1  J2  J3  J4  J5  J6  J7  J8  J9  J10

Légende:
─── Burndown idéal
●   Progression réelle

Statut: En bonne voie après ajustement jour 4
Prévision: Complet avec 2 pts de marge

Meilleures Pratiques

Pour les Backlogs de Sprint

1. Utilisez les données de vélocité — Ne devinez pas la capacité
2. Laissez une marge — 10-15% pour les imprévus
3. Priorisez impitoyablement — Éléments prioritaires d'abord
4. Prêt signifie prêt — Appliquez la Définition de Prêt
5. Protégez l'engagement — Résistez aux ajouts

Anti-Patterns

✗ S'engager sans données de vélocité
✗ Pas de marge pour les imprévus
✗ Éléments "presque prêts" dans le sprint
✗ Ajouter du travail mi-sprint régulièrement
✗ Ignorer les blocages jusqu'à ce qu'il soit trop tard
✗ Blâmer l'équipe pour mauvaise planification
✗ Pas de suivi de progression quotidien

Revue et Amélioration

Rétrospective sur la Planification

Après chaque sprint, évaluez:

1. Précision de l'estimation — Réel vs. engagé
2. Qualité de préparation — Éléments vraiment prêts?
3. Gestion de capacité — Calcul correct?
4. Gestion des dépendances — Blocages évités?
5. Communication — Équipe alignée?

Métriques à Suivre

Solutions Connexes

• Création de Backlogs Produit Efficaces
• Techniques d'Estimation Agile
• Gestion de Backlog Produit