Techniques d'Estimation Agile

L'estimation vise la compréhension, pas la précision. Une bonne estimation crée une compréhension partagée et permet la planification. Une mauvaise estimation soit surpromet, soit ajoute des marges excessives. Ce guide couvre les techniques d'estimation pratiques pour les équipes agiles.

Approches d'Estimation

Story Points

Estimation Relative

STORY POINTS
════════════

QUE SONT LES STORY POINTS :
─────────────────────────────────────
Mesure relative de :
├── Complexité
├── Effort
├── Incertitude
├── Combinés en un seul nombre
├── Pas des heures
└── Dimensionnement relatif

SÉQUENCE DE FIBONACCI :
─────────────────────────────────────
1, 2, 3, 5, 8, 13, 21

Pourquoi Fibonacci :
├── Plus grand = moins de précision
├── Force le choix entre options
├── Reconnaît l'incertitude
├── L'écart croît avec la taille
└── Reflète la réalité

STORIES DE RÉFÉRENCE :
─────────────────────────────────────
Établir une base :
├── 1 point : "Ajouter un champ au formulaire"
├── 3 points : "Nouvel endpoint API"
├── 5 points : "Fonctionnalité avec tests"
├── 8 points : "Intégration complexe"
├── 13 points : "Devrait être découpé"
├── Calibrage d'équipe
└── Comparer le nouveau aux références

CE QUE CAPTURENT LES POINTS :
─────────────────────────────────────
├── Complexité technique
├── Quantité de travail
├── Risque/incertitude
├── Lacunes de connaissances
├── Dépendances
├── Pas juste le temps
└── Vue holistique

Planning Poker

Estimation en Équipe

PLANNING POKER
══════════════

COMMENT ÇA MARCHE :
─────────────────────────────────────
1. Lire la story à voix haute
2. Répondre aux questions de clarification
3. Chacun sélectionne une carte (cachée)
4. Révéler simultanément
5. Discuter des différences
6. Re-voter si nécessaire
7. Consensus ou moyenne

EXEMPLE DE SESSION :
─────────────────────────────────────
Story : "Réinitialisation mot de passe utilisateur"

Tour 1 (révélation) :
├── Alice : 3
├── Bob : 8
├── Carol : 5
├── Dave : 5
└── Grand écart - discuter !

Discussion :
├── Bob : "Il faut intégrer le service email"
├── Alice : "On a déjà un helper email"
├── Carol : "Et le rate limiting ?"
├── Équipe : "Bon point, ajouter à la story"
└── Nouvelle compréhension

Tour 2 (révélation) :
├── Alice : 5
├── Bob : 5
├── Carol : 5
├── Dave : 5
└── Consensus : 5 points

POURQUOI ÇA MARCHE :
─────────────────────────────────────
├── Prévient l'ancrage (simultané)
├── Fait émerger différentes perspectives
├── La discussion construit la compréhension
├── L'équipe possède l'estimation
└── Engage tout le monde

T-Shirt Sizing

Estimation Rapide

T-SHIRT SIZING
══════════════

TAILLES :
─────────────────────────────────────
XS : Très petit, trivial
S  : Petit, bien compris
M  : Moyen, effort standard
L  : Grand, effort significatif
XL : Très grand, devrait être découpé

QUAND UTILISER :
─────────────────────────────────────
├── Planification de roadmap
├── Estimation initiale du backlog
├── Priorisation rapide
├── Items pas encore affinés
└── Discussions avec les parties prenantes

CONVERSION (optionnelle) :
─────────────────────────────────────
XS = 1 point
S  = 2-3 points
M  = 5 points
L  = 8-13 points
XL = À découper avant estimation

Affinity Mapping

Estimation en Volume

AFFINITY ESTIMATION
═══════════════════

PROCESSUS :
─────────────────────────────────────
1. Écrire chaque item sur une carte
2. Placer les cartes sur un mur
3. Silencieusement, grouper par taille similaire
4. Discuter des désaccords
5. Assigner des tailles aux groupes

DISPOSITION :
─────────────────────────────────────
┌───────┬───────┬───────┬───────┬───────┐
│  XS   │   S   │   M   │   L   │  XL   │
├───────┼───────┼───────┼───────┼───────┤
│ item  │ item  │ item  │ item  │ item  │
│ item  │ item  │ item  │ item  │ item  │
│       │ item  │ item  │ item  │       │
│       │       │ item  │       │       │
└───────┴───────┴───────┴───────┴───────┘

AVANTAGES :
─────────────────────────────────────
├── Rapide pour beaucoup d'items
├── Comparaison visuelle
├── Révèle les patterns
└── Engage toute l'équipe

Améliorer les Estimations

Rétrospective d'Estimation

RÉVISION DES ESTIMATIONS
════════════════════════

À CHAQUE SPRINT :
─────────────────────────────────────
1. Comparer estimé vs réel
2. Identifier les grandes variances
3. Comprendre pourquoi
4. Ajuster les références

QUESTIONS À POSER :
─────────────────────────────────────
├── "Qu'avons-nous sous-estimé ?"
├── "Qu'avons-nous surestimé ?"
├── "Qu'est-ce qui nous a surpris ?"
├── "Comment améliorer la prochaine fois ?"
└── "Nos références sont-elles à jour ?"

PATTERNS COURANTS :
─────────────────────────────────────
Sous-estimation :
├── Travail technique caché
├── Dépendances non identifiées
├── Complexité d'intégration
└── Tests insuffisamment prévus

Surestimation :
├── Réutilisation de code existant
├── Expérience acquise
├── Périmètre réduit après clarification
└── Aide inattendue

Anti-patterns à Éviter

Estimation et Vélocité

Construire la Vélocité

CYCLE DE VÉLOCITÉ
═════════════════

Sprint 1 : 
├── Estimations : 30 points
├── Complétés : 22 points
└── Vélocité : 22

Sprint 2 :
├── Engagement basé sur vélocité : 22 points
├── Complétés : 25 points
└── Vélocité : 25

Sprint 3 :
├── Engagement : 23-25 points
├── Complétés : 24 points
└── Vélocité moyenne : 24

PRÉVISIBILITÉ :
─────────────────────────────────────
Après 5-6 sprints :
├── Vélocité se stabilise
├── Prévisions plus fiables
├── Engagement confiant
└── Amélioration continue

Utiliser la Vélocité

PLANIFICATION AVEC VÉLOCITÉ
═══════════════════════════

DONNÉES :
├── Vélocité moyenne : 25 points/sprint
├── Backlog restant : 200 points
└── Durée du sprint : 2 semaines

CALCUL :
├── Sprints nécessaires : 200/25 = 8 sprints
├── Durée estimée : 16 semaines
└── Fourchette (±20%) : 13-19 semaines

COMMUNICATION :
─────────────────────────────────────
"Basé sur notre vélocité actuelle de 25 points
par sprint, nous estimons terminer le backlog
en 8 sprints, soit environ 16 semaines.
Fourchette probable : 13-19 semaines."

Cas Spéciaux

Items Non Estimables

QUAND NE PAS ESTIMER
════════════════════

SPIKES (RECHERCHE) :
├── Objectif : Réduire l'incertitude
├── Approche : Time-box (ex: 2 jours)
├── Résultat : Assez d'info pour estimer l'item réel
└── Pas de points, juste du temps alloué

BUGS CRITIQUES :
├── Priorité : Corriger immédiatement
├── Estimation : Après la correction
└── Tracking : Séparé de la vélocité normale

MAINTENANCE :
├── Option 1 : Buffer de temps (ex: 20% de la capacité)
├── Option 2 : Estimer comme les features
└── Conseil : Cohérence dans l'approche

Grandes Stories

DÉCOUPER LES GRANDES STORIES
════════════════════════════

SIGNES QU'IL FAUT DÉCOUPER :
├── Plus de 13 points
├── Prend plus d'un sprint
├── Trop de sous-tâches
├── Plusieurs fonctionnalités distinctes
└── Différentes personnes impliquées

TECHNIQUES DE DÉCOUPAGE :
─────────────────────────────────────
Par workflow : étape par étape utilisateur
Par données : différents types de données
Par règles : cas simples d'abord
Par interface : écran par écran
Par opérations : CRUD séparé

Solutions Connexes

• Planification de sprint
• Raffinement du backlog
• Gestion de la vélocité
• Métriques et KPIs agiles