7 min lecture • Guide 780 of 877
Métriques et KPIs Agiles
Les métriques influencent le comportement, alors choisissez-les avec soin. GitScrum fournit des analyses intégrées et un suivi personnalisé pour aider les équipes à s'améliorer continuellement.
Catégories de Métriques
Métriques de Flux
MÉTRIQUES DE FLUX :
┌─────────────────────────────────────────────────────────────┐
│ │
│ VÉLOCITÉ : │
│ Story points complétés par sprint │
│ Utilisation : Planification de sprint, capacité │
│ ⚠️ Ne pas : Comparer entre équipes │
│ │
│ Exemple : │
│ Sprint 10 : 24 points │
│ Sprint 11 : 28 points │
│ Sprint 12 : 22 points │
│ Moyenne : 25 points/sprint │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TEMPS DE CYCLE : │
│ Temps entre début et fin du travail │
│ Utilisation : Prévisibilité, amélioration du processus │
│ │
│ Exemple : │
│ Temps de cycle médian : 3,5 jours │
│ 85e percentile : 7 jours │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LEAD TIME : │
│ Temps entre la demande et la livraison │
│ Utilisation : Attentes client, SLAs │
│ │
│ Exemple : │
│ De "demandé" à "déployé" : 12 jours en moyenne │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DÉBIT : │
│ Nombre d'items complétés par période │
│ Utilisation : Prévision, planification de capacité │
│ │
│ Exemple : │
│ 8 stories/semaine (moyenne) │
│ Fourchette : 6-10 stories/semaine │
└─────────────────────────────────────────────────────────────┘
Métriques de Qualité
MÉTRIQUES DE QUALITÉ :
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAUX DE DÉFAUTS : │
│ Bugs trouvés par unité de travail │
│ Utilisation : Suivi des tendances qualité │
│ │
│ Exemple : │
│ 0,3 bugs par story (après QA) │
│ Tendance : En baisse (était 0,5 le trimestre dernier) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DÉFAUTS ÉCHAPPÉS : │
│ Bugs trouvés en production │
│ Utilisation : Efficacité des portes qualité │
│ │
│ Exemple : │
│ 2 bugs production ce sprint │
│ Cible : < 3 par sprint │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COUVERTURE DE CODE : │
│ Pourcentage de code avec tests │
│ Utilisation : Indicateur qualité tests (pas absolu) │
│ ⚠️ Haute couverture ≠ qualité │
│ │
│ Exemple : │
│ Global : 78% │
│ Nouveau code : 90% (cible : > 80%) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MTTR (Temps Moyen de Récupération) : │
│ Temps moyen pour corriger les problèmes production │
│ Utilisation : Efficacité de la réponse aux incidents │
│ │
│ Exemple : │
│ MTTR : 45 minutes (cible : < 1 heure) │
└─────────────────────────────────────────────────────────────┘
Métriques de Résultats
MÉTRIQUES DE RÉSULTATS :
┌─────────────────────────────────────────────────────────────┐
│ │
│ CE SONT LES PLUS IMPORTANTES : │
│ (Les métriques d'output sont des moyens vers ces fins) │
│ │
│ SATISFACTION UTILISATEUR : │
│ NPS, CSAT, feedback utilisateur │
│ Utilisation : Construisons-nous les bonnes choses ? │
│ │
│ Exemple : │
│ NPS : 45 (en hausse de 38 le trimestre dernier) │
│ Satisfaction fonctionnalités : 4,2/5 │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VALEUR BUSINESS : │
│ Impact sur les métriques business │
│ Utilisation : Notre travail a-t-il de l'impact ? │
│ │
│ Exemple : │
│ Conversion : +12% après lancement fonctionnalité │
│ Revenus : +50K€/mois attribués aux nouvelles features │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ADOPTION : │
│ Les utilisateurs utilisent-ils ce qu'on construit ? │
│ Utilisation : Validation des hypothèses produit │
│ │
│ Exemple : │
│ Adoption nouvelle feature : 67% des utilisateurs actifs │
│ Rétention : 85% après 30 jours │
└─────────────────────────────────────────────────────────────┘
Éviter les Dysfonctionnements
Pièges des Métriques
| Piège | Problème | Solution |
|---|---|---|
| Métriques individuelles | Compétition au lieu de collaboration | Métriques d'équipe uniquement |
| Objectifs de vélocité | Inflation des points | Focus sur le trend, pas la valeur |
| Punir les métriques basses | Masquage des problèmes | Utiliser pour améliorer, pas juger |
| Trop de métriques | Paralysie par l'analyse | 3-5 métriques clés max |
Utilisation Saine des Métriques
BONNES PRATIQUES
════════════════
✅ FAIRE :
├── Utiliser les métriques pour les conversations d'équipe
├── Se concentrer sur les tendances, pas les absolus
├── Laisser l'équipe choisir ses métriques
├── Combiner quantitatif et qualitatif
├── Réviser et ajuster régulièrement
└── Contextualiser pour les parties prenantes
❌ NE PAS FAIRE :
├── Comparer les vélocités entre équipes
├── Définir des objectifs de vélocité
├── Lier les métriques aux bonus
├── Mesurer les individus
├── Ignorer le contexte
└── Créer des métriques de vanité
Tableau de Bord Équilibré
Structure Recommandée
TABLEAU DE BORD MÉTRIQUES AGILES
════════════════════════════════
FLUX (comment le travail circule) :
├── Vélocité (tendance sur 6 sprints)
├── Temps de cycle (médiane + percentiles)
├── WIP (travail en cours actuel)
└── Débit (items par semaine)
QUALITÉ (quelle qualité produite) :
├── Défauts échappés en production
├── Taux de défauts post-QA
├── Couverture de tests nouveaux
└── MTTR incidents
LIVRAISON (respect des engagements) :
├── % objectif de sprint atteint
├── Prédictibilité (prévu vs réel)
├── Fréquence de déploiement
└── Taux de rollback
RÉSULTATS (impact réel) :
├── Satisfaction utilisateur
├── Métriques business clés
├── Adoption des features
└── Rétention
Métriques par Rôle
Ce Que Chaque Rôle Regarde
| Rôle | Métriques Prioritaires | Fréquence |
|---|---|---|
| Équipe Dev | Temps de cycle, WIP, blocages | Quotidien |
| Product Owner | Vélocité, adoption, satisfaction | Hebdomadaire |
| Scrum Master | Santé d'équipe, amélioration, flux | Sprint |
| Management | Résultats, valeur, tendances | Mensuel |
Mise en Œuvre
Démarrer le Suivi
ÉTAPES DE MISE EN PLACE
═══════════════════════
ÉTAPE 1 : CHOISIR LES MÉTRIQUES
├── Commencer avec 3-5 métriques max
├── Impliquer l'équipe dans le choix
├── Définir pourquoi chaque métrique
└── Définir comment mesurer
ÉTAPE 2 : ÉTABLIR LA BASELINE
├── Mesurer l'état actuel
├── Pas de jugement, juste observation
├── Documenter le contexte
└── Définir ce qui serait "mieux"
ÉTAPE 3 : VISUALISER
├── Tableau de bord accessible à tous
├── Mise à jour automatique si possible
├── Simple et lisible
└── Affiché dans l'espace d'équipe
ÉTAPE 4 : AGIR
├── Réviser en rétrospective
├── Identifier les patterns
├── Expérimenter des améliorations
└── Mesurer l'impact des changements
Fréquence de Révision
CALENDRIER DE RÉVISION
══════════════════════
QUOTIDIEN :
├── Burndown (standup)
├── WIP et blocages
└── Anomalies à signaler
FIN DE SPRINT :
├── Vélocité
├── Objectif sprint atteint
├── Défauts
└── Actions rétro basées sur données
MENSUEL :
├── Tendances sur plusieurs sprints
├── Métriques de qualité
├── Prédictibilité
└── Rapport aux parties prenantes
TRIMESTRIEL :
├── Vue d'ensemble
├── Métriques de résultats
├── Révision des métriques choisies
└── Ajustement du tableau de bord