Daily Scrum et burndown : piloter le Sprint au quotidien

StockPro a démarré son premier Sprint : un objectif clair, un Sprint Backlog rempli de tâches. Mais un Sprint sans pilotage dérive sans qu’on s’en aperçoive — on découvre le dernier jour que la moitié du travail n’avancera pas à temps. Le Daily Scrum est le rituel court qui empêche cette dérive : chaque jour, l’équipe regarde où elle en est par rapport à son objectif et ajuste son plan. Couplé à un graphique de suivi, le burndown, il rend l’avancement visible. À la fin de ce tutoriel, vous saurez tenir un Daily Scrum utile en quinze minutes et lire un burndown pour réagir à temps.

Ce que vous allez apprendre

• Le but exact du Daily Scrum et sa durée selon le Guide Scrum 2020.
• Pourquoi les fameuses « trois questions » ne sont plus obligatoires.
• Mettre à jour le Sprint Backlog au fil du Sprint.
• Construire et lire un burndown pour anticiper les dérapages.

Ce que vous allez construire

Vous repartirez avec un Daily Scrum cadré pour l’équipe StockPro et un burndown de Sprint tenu à jour, capable de vous signaler dès le milieu du Sprint si l’objectif est menacé.

Prérequis

• Un Sprint en cours avec un Sprint Backlog — voir Préparer et animer le Sprint Planning.
• Un tableau de tâches visible (colonnes À faire / En cours / Fait).
• Un endroit pour tracer le burndown : un tableur, un tableau blanc, ou un outil dédié.
• Niveau : débutant. Durée estimée : 25 minutes de lecture, puis quinze minutes par jour.

Étape 1 — Comprendre le but du Daily Scrum

Le Guide Scrum 2020 est précis sur la raison d’être du Daily Scrum : inspecter l’avancement vers l’objectif de Sprint et adapter le Sprint Backlog si nécessaire, en ajustant le travail prévu à venir. Ce n’est donc pas un rapport d’activité à un chef, ni un tour de table où chacun récite sa journée : c’est un moment de pilotage tourné vers l’objectif.

Le cadre est strict : le Daily Scrum est un événement de quinze minutes destiné aux Developers de l’équipe. Il se tient au même endroit et à la même heure chaque jour ouvré du Sprint, ce qui réduit la complexité et évite d’avoir à le planifier. Si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils y participent en tant que Developers.

✅ Point d’étape. Fixez dès aujourd’hui l’heure et le lieu du Daily de StockPro, et tenez-vous-y. La régularité fait la moitié de l’efficacité : un rituel à heure fixe ne se « cale » plus chaque jour.

Étape 2 — Oublier les « trois questions » obligatoires

Beaucoup d’équipes croient que le Daily Scrum consiste à répondre à trois questions : qu’ai-je fait hier, que ferai-je aujourd’hui, qu’est-ce qui me bloque ? C’était une technique populaire, et le Guide Scrum 2020 l’a délibérément retirée des obligations. Le Guide dit désormais que les Developers peuvent choisir la structure et les techniques qu’ils veulent, tant que le Daily Scrum se concentre sur l’avancement vers l’objectif de Sprint et produit un plan d’action pour la prochaine journée.

Pourquoi ce changement ? Parce que les trois questions glissaient vite vers le compte rendu individuel — chacun parlait à tour de rôle sans écouter — au lieu d’un travail collectif sur le plan. Pour StockPro, une approche plus efficace consiste à parcourir le tableau de droite à gauche : « qu’est-ce qui nous rapproche de l’objectif aujourd’hui, et qu’est-ce qui bloque une tâche en cours ? » On part du travail, pas des personnes.

L’animation concrète d’un stand-up — garder le rythme, éviter les digressions, faire participer chacun — relève d’un savoir-faire à part entière, détaillé dans Animer un stand-up et une rétrospective d’équipe.

Étape 3 — Faire vivre le Sprint Backlog

Le Daily Scrum n’a de sens que si le Sprint Backlog est à jour. Le Guide Scrum rappelle que le Sprint Backlog est mis à jour tout au long du Sprint à mesure que l’équipe apprend : il doit comporter assez de détail pour qu’on puisse inspecter l’avancement au Daily. Concrètement, avant ou pendant le Daily, l’équipe déplace les cartes sur le tableau, ajoute les tâches découvertes, et supprime celles devenues inutiles.

Sur StockPro, un Developer s’aperçoit que « décrémenter le stock » nécessite aussi de gérer le cas d’un stock déjà à zéro : une nouvelle tâche apparaît sur le tableau. Cette adaptation permanente est saine ; un Sprint Backlog figé au premier jour est le signe qu’on ne pilote pas vraiment.

✅ Point d’étape. À la fin de chaque Daily, le tableau doit refléter la réalité : aucune tâche « En cours » depuis trois jours sans explication, aucune tâche terminée encore à gauche. Le tableau ment ? Le pilotage ment aussi.

Étape 4 — Construire un burndown de Sprint

Le burndown est un graphique qui montre le travail restant au fil du Sprint. Précisons-le tout de suite : il ne fait pas partie du Guide Scrum 2020 : c’est une pratique complémentaire, optionnelle, que beaucoup d’équipes trouvent éclairante. En abscisse, les jours du Sprint ; en ordonnée, le travail restant (en points ou en nombre de tâches). On trace une ligne idéale du total de départ jusqu’à zéro au dernier jour, puis on reporte chaque jour le restant réel.

Restant
 22 |*
 18 |  \__ ideal
 14 |   *  \
 10 |      *  \
  6 |         * \
  2 |            *\
  0 |_______________\___ Jours
    J1  J3  J5  J7  J9

La lecture est immédiate. Si la courbe réelle reste au-dessus de la ligne idéale, on prend du retard ; si elle plonge sous la ligne, on avance plus vite que prévu. Une courbe plate pendant plusieurs jours est un signal d’alarme : rien ne se termine, sans doute parce que tout a été commencé en même temps. Pour StockPro, repérer ce plateau au milieu du Sprint laisse le temps de réagir : concentrer l’équipe sur moins de tâches à la fois pour en finir certaines.

Étape 5 — Réagir à ce que montre le suivi

Mesurer ne sert à rien sans décision. Si, au cinquième jour d’un Sprint de dix, le burndown de StockPro montre encore dix-huit tâches restantes sur vingt-deux, l’équipe a un choix lucide à faire au Daily. Plutôt que d’espérer un miracle, elle peut renégocier le périmètre avec le Product Owner : quelles stories sont indispensables à l’objectif de Sprint, lesquelles peuvent retourner au backlog ? L’objectif de Sprint, lui, reste le cap ; c’est le détail qui s’ajuste.

C’est tout l’esprit de l’empirisme : on n’attend pas la fin pour constater l’échec, on inspecte fréquemment et on adapte tôt. Le Daily et le burndown sont les instruments de bord de cette adaptation quotidienne.

✅ Point d’étape final. Après une semaine, vous devez pouvoir dire, burndown en main, si l’objectif de Sprint est en bonne voie. Si vous ne pouvez pas répondre, c’est que le suivi n’est pas assez tenu — corrigez cela avant tout.

Le Daily n’est pas le seul moment d’ajustement

Une idée fausse tenace voudrait que l’équipe ne touche à son plan qu’une fois par jour, au Daily. Le Guide Scrum 2020 dit l’inverse : le Daily Scrum n’est pas le seul moment où les Developers ajustent leur plan ; ils se concertent souvent tout au long de la journée pour discuter plus en détail de l’adaptation ou de la replanification du reste du Sprint. Le Daily est un point de synchronisation, pas une autorisation exceptionnelle à se parler.

Pour StockPro, cela veut dire qu’un Developer bloqué à 11 h n’attend pas le Daily du lendemain pour le dire : il sollicite un collègue immédiatement. Le Daily reste le rendez-vous qui garantit qu’au moins une fois par jour, toute l’équipe regarde l’objectif ensemble ; entre deux Daily, la collaboration continue librement. Cette nuance évite le travers d’équipes qui se figent entre deux rituels, comme si le plan n’avait le droit de bouger qu’à heure fixe.

Burndown ou burnup : deux lectures du même Sprint

Le burndown descend vers zéro ; son cousin le burnup monte. Au lieu de tracer le travail restant, le burnup trace le travail accompli qui grimpe vers une ligne de total. Les deux disent la même chose sous un autre angle, mais le burnup a un avantage : il distingue clairement deux causes de dérapage que le burndown mélange. Quand la ligne de total bouge, c’est que le périmètre a changé (on a ajouté ou retiré du travail) ; quand la courbe d’accompli stagne, c’est que la production ralentit.

Sur un burndown simple, ajouter une story en cours de Sprint fait remonter la courbe, ce qui ressemble à tort à une régression. Le burnup rend cet ajout lisible. Aucun des deux n’est imposé par Scrum : choisissez celui que votre équipe lit d’un coup d’œil. Pour débuter, le burndown suffit largement ; on passe au burnup quand les changements de périmètre en cours de Sprint deviennent fréquents et qu’on veut les comprendre.

Pièges fréquents

Récapitulatif

Le Daily Scrum est un événement de quinze minutes, pour les Developers, à heure et lieu fixes, dont le but est d’inspecter l’avancement vers l’objectif de Sprint et d’adapter le Sprint Backlog. Les trois questions historiques ne sont plus obligatoires : ce qui compte, c’est de produire un plan pour la journée. Le Sprint Backlog vit : on l’actualise en continu. Le burndown, pratique complémentaire, rend le travail restant visible et permet de réagir tôt plutôt que de subir. StockPro dispose désormais d’un tableau de bord quotidien fiable.

Aide-mémoire

À vous de jouer

Au septième jour d’un Sprint de dix, le burndown de StockPro est resté plat depuis trois jours : aucune tâche terminée. Que fait l’équipe au Daily ?

Tutoriels frères

• Sprint Review et Rétrospective — clôturer le Sprint et capitaliser sur ce que le suivi a révélé.
• Préparer et animer le Sprint Planning — d’où vient le Sprint Backlog que l’on pilote ici.

Ressources

• Vue d’ensemble : Scrum, le cadre Agile pour livrer un produit en équipe.
• Source de référence : le Guide Scrum 2020 (événement Daily Scrum).
• Pour la facilitation : Animer un stand-up et une rétrospective d’équipe.

FAQ

Le Scrum Master doit-il animer le Daily ?
Non. Le Daily appartient aux Developers. Le Scrum Master veille à ce qu’il ait lieu et reste dans les quinze minutes, mais ce sont les Developers qui le tiennent ; il peut s’effacer dès que l’équipe est autonome.

Faut-il vraiment supprimer les trois questions ?
Pas obligatoirement : elles restent une technique acceptable. Le changement de 2020 dit seulement qu’elles ne sont plus imposées. Si elles tournent au reporting, mieux vaut une autre approche centrée sur le travail.

Le burndown est-il indispensable ?
Non, c’est un outil complémentaire. Certaines équipes lui préfèrent un burnup ou un simple comptage de tâches restantes. L’essentiel est de rendre l’avancement visible, peu importe la forme.

Que faire si un blocage dépasse l’équipe ?
On le signale au Daily et le Scrum Master prend le relais pour le lever : c’est précisément sa mission. Le Daily sert à identifier l’obstacle, pas à le résoudre en quinze minutes.