khalilbenaz Team Velocity Tracker
Workflow
1. Définir le périmètre de mesure
- Confirmer la durée du sprint (1, 2 ou 3 semaines) — elle doit rester constante.
- Identifier la source de données : Jira, Azure DevOps, Linear, Shortcut.
- Décider de l'unité : story points (estimation relative) ou nombre de stories (throughput). Les deux métriques sont complémentaires.
2. Extraire les données brutes (6–10 sprints minimum)
Azure DevOps — requête WIQL pour extraire les stories complétées par sprint :
SELECT [System.Id], [System.Title], [Story Points], [System.IterationPath], [Microsoft.VSTS.Common.ClosedDate]
FROM WorkItems
WHERE [System.WorkItemType] = 'User Story'
AND [System.State] = 'Done'
AND [System.IterationPath] UNDER 'MonProjet\Sprint 1'
ORDER BY [Microsoft.VSTS.Common.ClosedDate] DESC
Jira — JQL équivalent :
project = MONPROJET AND issuetype = Story AND status = Done
AND sprint in closedSprints() ORDER BY sprint ASC
Export CSV via Azure DevOps CLI :
az boards query --wiql "SELECT [System.Id],[Story Points],[System.IterationPath] FROM WorkItems WHERE ..." --output table
3. Calculer les métriques fondamentales
| Métrique | Formule | Signal |
|---|---|---|
| Vélocité moyenne | Σ SP livrés / N sprints | Planification de release |
| Médiane | Valeur centrale des N sprints | Robuste aux outliers |
| Écart-type (σ) | √(Σ(x-μ)²/N) | Prévisibilité |
| Throughput | Nbre stories/sprint | Indépendant des estimations |
| Lead time | Date Done − Date Création | Réactivité end-to-end |
| Cycle time | Date Done − Date "In Progress" | Efficacité d'exécution |
Règle de décision sur la stabilité :
- σ < 20 % de la moyenne → équipe prévisible, planification fiable.
- σ entre 20–40 % → équipe instable, investiguer les causes.
- σ > 40 % → mesure non fiable, priorité à stabiliser avant de prévoir.
4. Construire les graphiques essentiels
Velocity chart (Python/pandas) :
import pandas as pd, matplotlib.pyplot as plt
df = pd.DataFrame({
'sprint': ['S1','S2','S3','S4','S5','S6'],
'sp': [32, 28, 35, 30, 33, 31]
})
mean_vel = df['sp'].mean()
df.plot(x='sprint', y='sp', kind='bar', title='Vélocité par sprint')
plt.axhline(mean_vel, color='red', linestyle='--', label=f'Moyenne {mean_vel:.0f} SP')
plt.legend(); plt.tight_layout(); plt.savefig('velocity.png')
Graphiques clés à produire :
- Burndown du sprint courant (SP restants vs. idéal).
- Velocity chart historique avec bande σ.
- Cumulative Flow Diagram (CFD) — détecter l'accumulation dans un état.
- Lead time distribution (histogramme + percentile 85).
5. Produire des prévisions par simulation Monte Carlo
Quand on a ≥ 10 sprints de throughput historique :
import random, statistics
throughput_history = [6, 7, 5, 8, 6, 7, 9, 6, 7, 8] # stories/sprint
backlog_remaining = 40 # stories à livrer
simulations = 10_000
results = []
for _ in range(simulations):
sprints, done = 0, 0
while done < backlog_remaining:
done += random.choice(throughput_history)
sprints += 1
results.append(sprints)
p50 = statistics.median(results)
p85 = sorted(results)[int(0.85 * simulations)]
p95 = sorted(results)[int(0.95 * simulations)]
print(f"50 % → {p50} sprints | 85 % → {p85} | 95 % → {p95}")
Lecture : présenter trois dates de livraison (optimiste P50, réaliste P85, pessimiste P95) plutôt qu'une date unique.
6. Analyser les tendances et anomalies
Checklist d'analyse :
- Sprints atypiques identifiés (congés, incidents, onboarding) → les exclure ou annoter, ne pas les corriger.
- CFD montre-t-il un goulot ? (largeur d'une colonne qui s'élargit = blocage).
- Cycle time en hausse → dette technique, WIP trop élevé, ou dépendances externes.
- Lead time > 3× cycle time → tickets restent trop longtemps en backlog.
- Vélocité en baisse progressive → signal d'alerte burnout ou dette.
7. Formuler des recommandations actionnables
Structurer chaque recommandation ainsi :
Problème observé : cycle time médian passé de 3 à 6 jours sur les 4 derniers sprints.
Hypothèse : revues de code bloquantes (> 48 h d'attente en moyenne).
Action : limiter WIP à N/2 (N = taille d'équipe), définir SLA review ≤ 1 jour ouvré.
Mesure du succès : cycle time < 4 jours d'ici 3 sprints.
Garde-fous & anti-patterns
| Anti-pattern | Risque | Correctif |
|---|---|---|
| Comparer la vélocité de deux équipes | Story points non comparables entre équipes | Utiliser le throughput si comparaison nécessaire |
| Augmenter la vélocité comme objectif | Inflation des estimations, qualité dégradée | La vélocité sert à prévoir, pas à évaluer la performance |
| Moyenne sur < 3 sprints | Statistiquement non significatif | Attendre 5+ sprints avant toute décision |
| Inclure les sprints 0 / perturbés | Fausse les projections | Annoter et exclure des calculs de base |
| Ignorer le WIP | Cache la vraie cause de lenteur | Afficher le WIP en temps réel sur le board |
| Prédire une date unique | Fausse confiance | Toujours présenter intervalles de confiance |
Bonnes pratiques 2026
- Flow metrics > story points : les équipes matures privilégient le cycle time et le throughput (pas d'estimation biaisée). Les story points restent utiles pour le capacity planning.
- Percentile 85 comme engagement : c'est le standard industry (Kanban Guide 2020+) pour les SLAs de livraison.
- CFD automatisé : configurer le CFD directement dans Azure DevOps (Analytics → Cumulative Flow) plutôt que de le construire manuellement.
- Sprint Review comme point de collecte : enregistrer la vélocité immédiatement après la review, avant tout ajustement.
- DORA metrics complémentaires : associer les métriques agile aux DORA metrics (deployment frequency, change failure rate) pour relier livraison agile et qualité opérationnelle.