Scrum est simple à comprendre, difficile à maîtriser. La plupart des équipes qui l’adoptent pratiquent un « Scrum de façade » : les cérémonies existent sur le papier, mais les bénéfices ne suivent pas. Voici ce qui fait la différence entre Scrum théorique et Scrum qui fonctionne.
Les trois piliers et pourquoi ils importent
Scrum repose sur trois piliers : transparence, inspection et adaptation. Ce ne sont pas des valeurs abstraites — ce sont des mécanismes concrets.
La transparence signifie que tout le monde voit la même chose : le backlog est visible et priorisé, la vélocité est publique, les impediments sont exposés, pas cachés.
L’inspection arrive lors des cérémonies — on regarde ce qui s’est passé objectivement, pas pour chercher des coupables.
L’adaptation : si l’inspection révèle un problème, on change quelque chose. Une équipe qui inspecte sans adapter perd son temps.
Sprint Planning : les questions à se poser
Le Sprint Planning produit deux choses : un Sprint Goal (pourquoi ce sprint ?) et une liste de tâches (comment l’atteindre ?). Le Sprint Goal est ce que beaucoup d’équipes oublient.
Sprint Goal efficace :
✅ "Permettre aux utilisateurs de payer par carte bancaire"
✅ "Réduire le temps de chargement de la page d'accueil sous 2 secondes"
Sprint Goal inefficace :
❌ "Finir les tickets PROJ-42, PROJ-47 et PROJ-51"
❌ "Sprint 14"Le Sprint Goal guide les décisions pendant le sprint. Si une User Story devient bloquée, l’équipe sait si elle peut la remplacer par une autre qui sert le même objectif.
Capacité réelle — ne planifiez jamais sur 100% de la capacité. Les interruptions, bugs urgents et réunions improductives prennent en moyenne 20 à 30% du temps. Une équipe de 5 personnes sur 2 semaines ne dispose pas de 400 heures — plutôt 280 à 300.
Daily Scrum : 15 minutes, pas un rapport de statut
Le Daily n’est pas une réunion de statut pour le Scrum Master. C’est une synchronisation de l’équipe pour elle-même.
❌ Format statut (à éviter) :
"Hier j'ai travaillé sur PROJ-42. Aujourd'hui je continue sur PROJ-42. Pas de blocage."
✅ Format collaboration :
"J'ai fini la partie back du paiement. J'ai besoin de Marie pour les maquettes
du formulaire — c'est le dernier blocage avant de clore la US.
On peut se voir 10 minutes après le Daily ?"Si le Daily prend plus de 15 minutes, c’est un signal que les discussions détaillées se font dans la mauvaise réunion. Terminez à 15 minutes, finissez les conversations en bilatéral.
Sprint Review vs Retrospective : deux réunions différentes
Beaucoup d’équipes confondent les deux ou les fusionnent — c’est une erreur.
Sprint Review — orientée produit. On montre ce qui a été construit aux stakeholders, on recueille du feedback, on met à jour le Product Backlog. Les stakeholders sont présents.
Retrospective — orientée équipe. On parle de comment on travaille ensemble, pas de ce qu’on a livré. Les stakeholders ne sont pas présents (sauf Scrum Master et Product Owner).
Retrospective : structure simple en 3 questions
1. Qu'est-ce qui a bien fonctionné ? (à continuer)
2. Qu'est-ce qui a moins bien fonctionné ? (à améliorer)
3. Une action concrète pour le prochain sprint (avec un responsable et une deadline)Une Retro sans action concrète est une thérapie de groupe — agréable mais sans impact.
Definition of Done : le contrat de qualité
La Definition of Done (DoD) est l’accord de l’équipe sur ce que “terminé” signifie. Une User Story n’est pas Done tant que tous les critères ne sont pas satisfaits.
Definition of Done — exemple :
□ Code mergé sur main via Pull Request reviewée par au moins 1 autre développeur
□ Tests unitaires écrits et passants (couverture ≥ 80% sur le nouveau code)
□ Tests d'intégration passants en CI
□ Quality Gate SonarQube verte
□ Documentation technique mise à jour si applicable
□ Déployé en staging et testé manuellement
□ Product Owner a validé que les critères d'acceptation sont remplisSans DoD explicite, “Done” veut dire quelque chose de différent pour chaque membre de l’équipe — source de dette technique et de bugs en production.
Les anti-patterns les plus courants
Scrum but — “On fait Scrum, mais sans les Daily”, “On fait Scrum, mais le Sprint Backlog change en cours de sprint”. Chaque “but” retire une brique du système et dégrade l’ensemble.
Tickets sans critères d’acceptation — “En tant qu’utilisateur, je veux pouvoir me connecter” n’est pas une User Story complète. Sans critères d’acceptation, personne ne sait quand c’est vraiment terminé.
Vélocité comme objectif — la vélocité est un outil de planification, pas un KPI de performance. Une équipe qui maximise sa vélocité en réduisant ses standards de qualité fait exactement le contraire de ce que Scrum vise.
Sprint sans Sprint Goal — sans objectif partagé, le sprint est une liste de tâches. L’équipe perd la capacité de s’adapter et de faire des arbitrages intelligents en cours de sprint.
Notre formation Agile & Scrum couvre ces pratiques avec des simulations et des retours sur des cas réels d’équipes.