| name | management-team-velocity-tracker |
| description | Suivi de la vélocité d'équipe et des métriques agile pour piloter la performance et la prévisibilité. Se déclenche avec "vélocité", "burndown", "lead time", "cycle time", "throughput", "métriques agile". Also triggers on "team velocity", "agile metrics", "predictability of the team". |
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]
backlog_remaining = 40
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 :
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.
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.
