Bonjour !
Dans la leçon précédente, nous avons exploré la rétrospective de Sprint, un événement crucial pour l'amélioration continue du processus de l'équipe. Vous avez appris à animer cette cérémonie pour aider l'équipe à s'inspecter et à s'améliorer.
Aujourd'hui, nous allons nous concentrer sur le pilotage et le suivi de l'avancement. En tant que futur chef de projet technique ou Tech Lead, vous aurez besoin d'indicateurs clairs pour savoir où en est le projet, si l'équipe est sur la bonne voie, et quand vous pouvez espérer livrer de la valeur. L'objectif de cette leçon est donc de vous apprendre à mettre en place et interpréter des indicateurs de suivi agiles, en particulier la vélocité et le burndown chart.
Ces deux outils sont comme le tableau de bord de votre projet agile. Bien compris, ils vous permettent de naviguer avec une meilleure visibilité et d'anticiper les obstacles. Mal interprétés, ils peuvent devenir des sources de pression et de mauvaises décisions. Notre but est de faire de vous un pilote éclairé.
1. La Vélocité : Le "moteur" de votre équipe
Commençons par la vélocité. C'est un concept simple en apparence, mais souvent mal utilisé. Il mesure la "capacité de production" de l'équipe.
1.1. Qu'est-ce que la vélocité ?
La vélocité représente la quantité de travail (mesurée en points de complexité) que l'équipe Scrum arrive à transformer en incrément "Terminé" (Done) au cours d'un seul Sprint.
Pour bien comprendre ce que c'est, et surtout comment on la calcule de manière fiable, la vidéo suivante est une excellente introduction.
Comment bien utiliser la vélocité - Scrum Life 19
La vidéo "Comment bien utiliser la vélocité" de la chaîne Scrum Life définit la vélocité et insiste sur un point crucial : l'utilisation d'une moyenne pour la rendre fiable.
Regardez le début de la vidéo jusqu'à 01:21. Portez attention à la définition de la vélocité et à la raison pour laquelle on utilise une moyenne sur plusieurs Sprints (idéalement 8) pour la planification.
Ce qu'il faut retenir est que la vélocité n'est pas une mesure ponctuelle, mais une moyenne observée sur plusieurs Sprints. Une équipe qui vient de terminer un Sprint avec 40 points n'a pas une "vélocité de 40". Si les Sprints précédents étaient à 5, 25, et 30 points, sa vélocité moyenne est plus proche de (40+5+25+30)/4 = 25 points. C'est cette moyenne qui nous sera utile.
1.2. À quoi sert la vélocité ? La planification à long terme
La principale utilité de la vélocité est la prévision à long terme (planification de release). Elle aide à répondre à la question que tous les clients et managers posent : "Quand est-ce que ce sera fini ?".
La formule de base est simple :
Le guide "Scrum et XP depuis les Tranchées" offre un exemple très concret de la manière dont cette planification est mise en œuvre.
Scrum et XP depuis les Tranchées
Le livre blanc "Scrum et XP depuis les Tranchées" d'Henrik Kniberg est une référence. Nous allons voir comment il utilise la vélocité pour construire un plan de release.
Lisez les sections intitulées "Tout mettre ensemble dans un plan de release" (p. 95) et "Adapter le plan de release" (p. 96). Concentrez-vous sur la manière dont les User Stories sont réparties en Sprints en fonction de la vélocité estimée, et comment ce plan est révisé après chaque Sprint.
Comme vous l'avez lu, la vélocité permet de découper le backlog en "paquets" de Sprints probables. C'est un outil de conversation puissant avec les parties prenantes. Il ne donne pas une date de livraison gravée dans le marbre, mais plutôt une fenêtre de livraison probable, qui s'affine au fil du temps.
L'image ci-dessous montre un "Product Burndown Chart", qui est une visualisation de cette planification à long terme. On y voit le travail restant (barres bleues) diminuer Sprint après Sprint, au rythme de la vélocité de l'équipe (ligne jaune).
1.3. Les pièges à éviter : Comment NE PAS utiliser la vélocité
C'est ici que votre rôle de leader devient crucial. La vélocité est un outil de planification, pas un indicateur de performance. Son utilisation abusive est l'une des dérives les plus courantes et les plus toxiques en Agile.
La suite de la vidéo sur la vélocité détaille brillamment ces pièges.
Comment bien utiliser la vélocité - Scrum Life 19
Cette partie de la vidéo "Comment bien utiliser la vélocité" est fondamentale. Elle vous armera contre les mauvaises pratiques que vous rencontrerez inévitablement.
Regardez attentivement de 01:21 à la fin de la vidéo. Notez les trois principales dérives : 1) L'utiliser pour l'engagement en Sprint Planning, 2) L'utiliser comme un indicateur de performance (et comparer les équipes), 3) Pousser pour l'augmenter à tout prix.
En résumé, voici ce que vous devez absolument retenir et défendre :
- La vélocité N'EST PAS un outil d'engagement. L'équipe décide du contenu d'un Sprint en décomposant les premières User Stories en tâches, pas en se disant "notre vélocité est de 25, donc on prend 25 points".
- La vélocité N'EST PAS un indicateur de performance. Comparer la vélocité de deux équipes n'a aucun sens, car leurs estimations sont relatives. Pousser une équipe à "augmenter sa vélocité" ne mène qu'à l'inflation des estimations ou à une baisse de la qualité.
- Une vélocité STABLE est plus précieuse qu'une vélocité ÉLEVÉE. Un graphique de vélocité en dents de scie est le signe d'une équipe imprévisible. Une vélocité stable, même modeste, indique une équipe prédictible, ce qui rend la planification fiable. C'est ça, le véritable objectif.
Testez votre compréhension !
Un manager vient vous voir et vous dit : "L'équipe A a une vélocité de 40 points par Sprint et l'équipe B n'est qu'à 25. Il faut que le Scrum Master de l'équipe B les coache pour qu'ils atteignent 40 points, comme l'équipe A."
En tant que futur Tech Lead, que répondez-vous ?
Show answer
C'est une excellente occasion d'éduquer le manager. Une réponse pourrait être :
"Je comprends l'objectif d'améliorer la performance, mais comparer la vélocité de deux équipes est trompeur. Les 'points' sont une mesure relative et propre à chaque équipe. 40 points pour l'équipe A ne représentent pas la même quantité de travail que 40 points pour l'équipe B.
Ce qui est important pour l'équipe B, ce n'est pas d'atteindre 40, mais d'avoir une vélocité prédictible. Si leur vélocité est stable autour de 25, c'est une excellente nouvelle : cela signifie que nous pouvons faire des prévisions fiables sur leurs livraisons. Tenter de 'gonfler' ce chiffre artificiellement nuirait à cette prédictibilité et à la qualité de leur travail. Si nous voulons les aider, nous devrions plutôt nous concentrer, en rétrospective, sur les obstacles qui les empêchent d'être plus stables et sereins."
2. Le Burndown Chart : Le "GPS" du Sprint
Alors que la vélocité nous aide à voir loin, le Burndown Chart est notre outil de navigation à court terme, à l'échelle d'un Sprint.
2.1. Qu'est-ce que le Burndown Chart ?
Le Burndown Chart est un graphique qui montre la quantité de travail restante par rapport au temps qui passe durant un Sprint.
Il y a deux lignes clés :
- La ligne idéale : Une droite qui part du total du travail estimé le premier jour et qui arrive à zéro le dernier jour.
- La ligne réelle : La courbe qui montre le travail restant réel, mise à jour quotidiennement.
L'objectif de ce graphique est de rendre visible l'avancement de l'équipe vers son objectif de Sprint et de déclencher des conversations si la ligne réelle dévie trop de la ligne idéale.
2.2. Interpréter les histoires que raconte la courbe
Un Burndown Chart est rarement une ligne droite. Ses formes révèlent beaucoup de choses sur la vie de l'équipe pendant le Sprint.
Le site Scrum-League propose d'excellents exemples de "patterns" de Burndown et leur signification.
Cette page web est une galerie de Burndown Charts. En analysant les différents graphiques, vous apprendrez à diagnostiquer rapidement les problèmes potentiels d'un Sprint.
Lisez la section "Qu’est-ce que peut dire un burndown chart ?". Observez chaque image de graphique et lisez l'interprétation associée. Faites le lien entre la forme de la courbe (plate, qui remonte, qui chute à la fin) et les problèmes possibles (dette technique, ajout de périmètre, validation tardive).
2.3. Mettre en place un Burndown Chart UTILE
Vous avez vu qu'un Burndown Chart peut être trompeur. Le piège le plus courant est de "burner" (décompter) des tâches ou des heures. Une équipe peut avoir fait 95% des tâches d'une User Story, le Burndown semblera presque parfait, mais la valeur pour l'utilisateur (la Story) est toujours de 0.
La vidéo suivante expose cette dérive et donne la solution pour créer un Burndown qui mesure ce qui compte vraiment : la livraison de valeur.
Les Dérives du Burn-Down Chart - Scrum Life 2
La vidéo "Les Dérives du Burn-Down Chart" de Scrum Life est une démonstration percutante de la façon dont un indicateur peut être détourné. Elle vous montrera comment construire un graphique qui sert réellement l'équipe.
Regardez la vidéo à partir de 02:13 jusqu'à la fin. Concentrez-vous sur la différence entre un Burndown qui suit les tâches et un qui suit les User Stories. La conclusion est la clé : pour être utile, le Burndown Chart doit mesurer le travail restant en se basant sur les User Stories entièrement terminées.
La meilleure pratique est donc la suivante : le Burndown Chart doit décompter les points d'une User Story uniquement lorsque celle-ci est 100% "Done". Le graphique ne descendra pas de manière lisse, il ressemblera à un escalier. C'est normal ! Mais chaque marche vers le bas représentera une valeur réelle et tangible qui a été livrée, et non une simple "activité". Cela pousse l'équipe à se concentrer sur la finalisation des éléments plutôt que de commencer plein de choses en parallèle.
Testez votre compréhension !
Vous observez le Burndown Chart de votre équipe. La courbe reste plate pendant la quasi-totalité du Sprint, puis chute brutalement les deux derniers jours pour presque atteindre zéro.
Quelles sont vos hypothèses ? Quelles questions poseriez-vous à l'équipe lors du Daily Scrum ou de la prochaine rétrospective ?
Show answer
Hypothèses possibles :
- Le "Syndrome de l'étudiant" : L'équipe a procrastiné ou a mal synchronisé son travail, et tout a été fait/testé/intégré dans l'urgence à la fin.
- Validation tardive : Le travail était fait, mais le Product Owner n'a validé les User Stories que les derniers jours, ce qui a retardé le moment où elles sont passées à "Done".
- Obstacle majeur : Un problème technique bloquant a paralysé l'équipe pendant la majeure partie du Sprint, et il n'a été résolu qu'à la fin.
- Mauvais indicateur : L'équipe attend la fin du Sprint pour mettre à jour l'outil de suivi.
Questions à poser à l'équipe (avec bienveillance) :
- "J'ai remarqué sur le Burndown que beaucoup de choses se sont terminées en même temps à la fin. Comment avez-vous vécu la fin du Sprint ? Était-ce une course ?"
- "Y a-t-il eu un moment où vous vous êtes sentis bloqués et où le travail ne pouvait pas avancer ?"
- "Comment se passe notre processus de validation avec le Product Owner ? Arrivons-nous à lui présenter les stories au fur et à mesure qu'elles sont prêtes ?"
- "En rétrospective, nous pourrions discuter : comment pourrions-nous lisser notre flux de travail pour éviter les pics de stress en fin de Sprint ?"
L'objectif n'est pas d'accuser, mais d'utiliser le graphique comme point de départ pour une discussion d'amélioration.
Conclusion
Vous avez maintenant les clés pour comprendre et utiliser les deux principaux indicateurs de suivi de Scrum.
Les points clés à retenir :
- La Vélocité est un indicateur de planification à long terme. Elle sert à prévoir et à s'adapter. Sa stabilité est plus importante que sa valeur absolue. C'est un outil pour l'équipe et le Product Owner.
- Le Burndown Chart est un indicateur de suivi à court terme (Sprint). Il aide l'équipe à s'auto-organiser et à visualiser son avancée vers l'objectif de Sprint. Il est plus utile lorsqu'il suit les User Stories terminées.
- Ce sont des outils de conversation, pas de jugement. Leur but est de rendre les problèmes visibles pour que l'équipe puisse en discuter et agir. En tant que leader, votre rôle est de les protéger de toute interprétation abusive.
La maîtrise de ces outils vous donnera une vision claire et factuelle de la dynamique de vos projets, une compétence indispensable pour tout chef de projet ou Tech Lead.
Dans la prochaine leçon, nous ouvrirons un nouveau module sur la Gestion des Risques et des Problèmes. Nous commencerons par la base : apprendre à distinguer un risque (un événement incertain futur) d'un problème (un événement avéré). Cela s'inscrit parfaitement dans la continuité : une courbe de Burndown qui dérape est un problème à traiter. La gestion des risques, que nous allons aborder, nous apprendra à anticiper ces dérapages avant même qu'ils ne se produisent.