Story Points vs Effort Points : Guide d'Estimation

Les story points et effort points mesurent tous deux la complexité du travail, mais ils abordent l'estimation différemment. GitScrum utilise des effort points avec une échelle simplifiée (XS à XL) qui inclut des guides horaires, rendant l'estimation plus accessible aux équipes tout en maintenant les avantages du dimensionnement relatif des story points.

Aperçu Comparatif

Comprendre les Story Points

STORY POINTS TRADITIONNELS
══════════════════════════

CONCEPT :
─────────────────────────────────────
Les story points mesurent la complexité RELATIVE
Pas des heures, pas des jours - comparaison pure

"Quelle est la complexité de la Tâche B vs Tâche A ?"
Si Tâche A = 3 points et Tâche B est deux fois plus complexe
Alors Tâche B = 5 ou 8 points

ÉCHELLE FIBONACCI :
─────────────────────────────────────
1  - Trivial (ligne de base de référence)
2  - Simple
3  - Petit
5  - Moyen
8  - Grand
13 - Très grand
21 - Épique (doit être divisé)

POURQUOI FIBONACCI ?
─────────────────────────────────────
├── L'incertitude croît avec la taille
├── Difficile de distinguer 14 vs 15
├── Les écarts forcent des choix significatifs
└── Reflète les limites naturelles d'estimation

EXEMPLE :
─────────────────────────────────────
Tâche de référence : "Ajouter validation au form" = 3 pts

Comparant nouvelles tâches :
├── "Changer couleur du bouton" → plus petit → 1 pt
├── "Ajouter date picker" → similaire → 3 pts
├── "Construire dashboard utilisateur" → beaucoup plus grand → 13 pts
└── "Implémenter système auth" → épique → 21 pts (diviser !)

Comprendre les Effort Points

EFFORT POINTS GITSCRUM
══════════════════════

CONCEPT :
─────────────────────────────────────
Les effort points combinent le dimensionnement
relatif avec des guides horaires optionnels

Mêmes avantages de comparaison relative
Plus références temporelles pratiques

ÉCHELLE DE TAILLES AVEC HEURES :
─────────────────────────────────────
┌────────┬─────────┬─────────────────────┐
│ Taille │ Points  │ Durée Typique       │
├────────┼─────────┼─────────────────────┤
│ XS     │ 1       │ Moins de 2 heures   │
│ S      │ 2       │ 2-4 heures          │
│ M      │ 3       │ 4-8 heures (1 jour) │
│ L      │ 5       │ 1-2 jours           │
│ XL     │ 8       │ 2-5 jours           │
└────────┴─────────┴─────────────────────┘

POURQUOI ÇA FONCTIONNE :
─────────────────────────────────────
├── Simple à comprendre
├── Seulement 5 options à choisir
├── Les guides horaires réduisent les débats
├── Permet toujours le suivi de vélocité
└── Fonctionne pour équipes nouvelles et expérimentées

EXEMPLE :
─────────────────────────────────────
Tâche : "Ajouter édition du profil utilisateur"

En décomposant :
├── Correction rapide ? Moins de 2 hrs ? → XS (1 pt)
├── Travail d'une demi-journée ? → S (2 pts)
├── Effort d'une journée complète ? → M (3 pts)
├── Quelques jours ? → L (5 pts)
└── Semaine de travail ? → XL (8 pts)

Consensus de l'équipe : "Environ 2 jours" → L (5 pts)

Quand Utiliser Chacun

CHOISIR VOTRE APPROCHE
══════════════════════

UTILISEZ EFFORT POINTS QUAND :
─────────────────────────────────────
✓ Équipe nouvelle à l'estimation agile
✓ Les parties prenantes demandent "combien de temps ?"
✓ Besoin de références concrètes de planification
✓ Niveaux d'expérience mixtes dans l'équipe
✓ Plus simple est mieux pour votre contexte
✓ Conversion depuis estimations en heures

UTILISEZ STORY POINTS QUAND :
─────────────────────────────────────
✓ Équipe a une pratique d'estimation mature
✓ La complexité abstraite fonctionne bien
✓ Besoin de granularité Fibonacci
✓ L'équipe résiste aux associations temporelles
✓ Grande variance dans les vitesses individuelles
✓ Vous avez déjà une vélocité établie

APPROCHE HYBRIDE :
─────────────────────────────────────
Les effort points GitScrum supportent les deux :
├── Utilisez les tailles (visuel)
├── Suivez les valeurs de points (numérique)
├── Référencez les heures (optionnel)
└── Calculez la vélocité (comme story points)

Techniques d'Estimation

COMMENT ESTIMER
═══════════════

PLANNING POKER :
─────────────────────────────────────
1. Présenter la tâche/story
2. Discuter des exigences
3. Tout le monde choisit une taille simultanément
4. Révéler les choix
5. Discuter des outliers
6. Re-voter si nécessaire
7. Consensus ou moyenne

Exemple de session :
┌─────────────────────────────────────┐
│ Tâche : "Implémenter reset mdp"     │
├─────────────────────────────────────┤
│ Vote 1 :                            │
│ Dev A : M    Dev B : L    Dev C : M │
│                                     │
│ Discussion : "Et l'email ?"         │
│ Dev B : "J'ai oublié le template"   │
│                                     │
│ Vote 2 :                            │
│ Dev A : M    Dev B : M    Dev C : M │
│                                     │
│ Consensus : M (3 points)            │
└─────────────────────────────────────┘

TAILLES DE T-SHIRT :
─────────────────────────────────────
Méthode de dimensionnement rapide :

1. Trier les tâches par complexité
2. Attribuer des tailles
3. Convertir en points

┌────────────────────────────────────────┐
│ XS │ S │ M │ L │ XL │                  │
├────┼───┼───┼───┼────┤                  │
│ T1 │T2 │T4 │T6 │ T8 │ ← Tâches triées  │
│    │T3 │T5 │T7 │    │                  │
│    │   │   │   │    │                  │
└────┴───┴───┴───┴────┘

COMPARAISON DE RÉFÉRENCE :
─────────────────────────────────────
1. Établir des tâches de référence par taille
2. Comparer les nouvelles tâches aux références
3. Associer à la référence la plus proche

Bibliothèque de références :
├── XS : "Mettre à jour valeur config"
├── S :  "Ajouter validation de form"
├── M :  "Créer nouvel endpoint API"
├── L :  "Construire widget dashboard"
└── XL : "Implémenter intégration"

Planification de Sprint avec Points

PLANIFICATION DE CAPACITÉ
═════════════════════════

CALCUL DE LA CAPACITÉ :
─────────────────────────────────────
Équipe : 4 développeurs
Sprint : 2 semaines (10 jours ouvrés)
Vélocité historique : 35-40 pts/sprint

Capacité disponible :
├── Tenir compte des congés, réunions
├── Inclure buffer pour imprévus
└── Ne pas surengager

Exemple :
┌─────────────────────────────────────┐
│ CAPACITÉ DU SPRINT                  │
├─────────────────────────────────────┤
│ Vélocité historique : 38 pts avg    │
│ Ce sprint :                         │
│ ├── Dev A : Complet (10 jours)      │
│ ├── Dev B : Complet (10 jours)      │
│ ├── Dev C : 8 jours (2 congés)      │
│ └── Dev D : Complet (10 jours)      │
│                                     │
│ Capacité ajustée : 38 × 0.9 = 34 pts│
│ Buffer (10%) : 3 pts                │
│ Engagement sûr : 31 pts             │
└─────────────────────────────────────┘

BACKLOG DU SPRINT :
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Story/Tâche            │ Effort    │
├────────────────────────┼───────────┤
│ Édition profil user    │ L (5 pts) │
│ Flux reset mot de passe│ M (3 pts) │
│ Widgets tableau de bord│ L (5 pts) │
│ API rate limiting      │ M (3 pts) │
│ Bug : Login timeout    │ S (2 pts) │
│ Notifications email    │ L (5 pts) │
│ Page paramètres        │ M (3 pts) │
│ Mise à jour docs       │ S (2 pts) │
├────────────────────────┼───────────┤
│ TOTAL ENGAGÉ           │ 28 pts    │
│ Buffer restant         │ 3 pts     │
└────────────────────────┴───────────┘

Suivi de Vélocité

MESURER LA VÉLOCITÉ
═══════════════════

QU'EST-CE QUE LA VÉLOCITÉ ?
─────────────────────────────────────
Points complétés par sprint
Moyenne au fil du temps = capacité prévisible

Sprint    │ Engagé      │ Complété
──────────┼─────────────┼──────────
Sprint 1  │ 35 pts      │ 32 pts
Sprint 2  │ 35 pts      │ 36 pts
Sprint 3  │ 38 pts      │ 35 pts
Sprint 4  │ 35 pts      │ 38 pts
Sprint 5  │ 38 pts      │ 37 pts
──────────┼─────────────┼──────────
Moyenne   │             │ 35.6 pts

GRAPHIQUE DE VÉLOCITÉ :
─────────────────────────────────────
Points│
   40 │      ■         ■
      │  ■       ■         ■
   35 │──────────────────────  Moyenne
      │
   30 │  ■
      │
   25 ├──────────────────────────
      S1  S2  S3  S4  S5  S6

UTILISER LA VÉLOCITÉ :
─────────────────────────────────────
├── Planifier les futurs sprints
├── Projeter les dates de complétion
├── Identifier les changements de capacité
├── Détecter la dérive d'estimation
└── Communiquer avec les parties prenantes

Exemple de projection :
Travail restant : 180 points
Vélocité : 36 pts/sprint
Sprints estimés : 5 (10 semaines)

Erreurs Courantes

ANTI-PATTERNS D'ESTIMATION
══════════════════════════

ERREUR 1 : CONVERTIR EN HEURES
─────────────────────────────────────
❌ "1 point = 4 heures"
❌ "Combien d'heures fait un L ?"
❌ Traiter les points comme des unités de temps

✓ Les points mesurent la complexité, pas le temps
✓ Les guides horaires sont des références, pas des règles
✓ La vélocité normalise avec le temps

ERREUR 2 : ESTIMATIONS INDIVIDUELLES
─────────────────────────────────────
❌ "C'est 5 points pour moi"
❌ Ajuster pour la vitesse individuelle
❌ Échelles différentes par personne

✓ Estimations d'équipe (consensus)
✓ Échelle unique pour tous
✓ La vélocité tient compte du mix d'équipe

ERREUR 3 : NE JAMAIS RECALIBRER
─────────────────────────────────────
❌ Mêmes références pour toujours
❌ Ignorer la dérive d'estimation
❌ Ne pas revoir réels vs estimés

✓ Revoir les tâches de référence trimestriellement
✓ Comparer estimés aux réels
✓ Ajuster quand l'équipe change

ERREUR 4 : SUR-PRÉCISION
─────────────────────────────────────
❌ "C'est exactement 4.5 points"
❌ Débattre XS vs S pendant 20 minutes
❌ Paralysie par l'analyse

✓ Accepter l'incertitude d'estimation
✓ Arrondir à la taille la plus proche
✓ Timeboxer les discussions (2 min/item)

Bonnes Pratiques

1. Estimer en équipe - le consensus construit une compréhension partagée
2. Utiliser des tâches de référence - comparer, pas calculer
3. Suivre la vélocité - les patterns émergent après 5+ sprints
4. Tout inclure - tests, revue, documentation
5. Diviser les gros items - rien au-dessus de XL/8 points
6. Timeboxer l'estimation - 2 minutes par item maximum
7. Revoir régulièrement - rétro sur la précision d'estimation
8. Faire confiance au processus - la vélocité normalise la variance

Configuration dans GitScrum

CONFIGURER LES EFFORT POINTS
════════════════════════════

ESTIMATION DES TÂCHES :
─────────────────────────────────────
En créant/éditant une tâche :
1. Ouvrir les détails de la tâche
2. Trouver le champ Effort
3. Sélectionner taille : XS, S, M, L, XL
4. Points calculés automatiquement

VUE DE PLANIFICATION DE SPRINT :
─────────────────────────────────────
Le backlog du sprint montre :
├── Total des points engagés
├── Seuil de capacité
├── Efforts des tâches individuelles
└── Suivi de progression

RAPPORTS DE VÉLOCITÉ :
─────────────────────────────────────
Workspace → Reports → Sprint KPIs
├── Points par sprint
├── Taux de complétion
├── Progression du burndown
└── Analyse des tendances

Solutions Connexes

• Planification et Exécution de Sprint
• Techniques d'Estimation Agile
• Guide de Suivi de Vélocité
• Dette Technique avec Effort Points