Le sprint est le coeur du framework Scrum: une période de durée fixe, généralement deux semaines, pendant laquelle l’équipe transforme un ensemble d’éléments du product backlog (la liste ordonnée de tout ce qui pourrait être nécessaire au produit) en un incrément livrable. Le Scrum Guide 2020 le décrit comme un “événement conteneur” dans lequel tous les autres événements Scrum prennent place. Mais concrètement, que se passe-t-il chaque jour?
Le premier jour: poser les fondations
Le sprint démarre par le sprint planning, une séance de planification dont la durée maximale est de quatre heures pour un sprint de deux semaines. Cette séance s’organise autour de trois questions successives, dont la première porte sur la valeur: pourquoi ce sprint est-il important? L’équipe définit un sprint goal (objectif du sprint), une phrase qui donne une direction claire et permettra de prendre des décisions cohérentes pendant les deux semaines à venir. Sans sprint goal explicite, le sprint se réduit à une liste de tâches sans fil conducteur.
La deuxième question concerne le périmètre: quels éléments du product backlog l’équipe peut-elle raisonnablement terminer? Le Product Owner présente les items prioritaires et l’équipe, en fonction de sa vélocité passée et de sa capacité réelle (congés, formations, autres engagements), sélectionne ceux qu’elle s’engage à livrer.
La troisième question est celle du comment: l’équipe décompose les items sélectionnés en tâches concrètes, créant ainsi le sprint backlog (le plan de travail du sprint). Cette décomposition reste un exercice de prévision, pas un engagement contractuel. Le plan s’affinera au fil des jours.
Du deuxième jour au dernier: le rythme quotidien
Le daily scrum, chaque matin
Chaque jour ouvré, l’équipe se réunit pendant quinze minutes maximum, toujours à la même heure et au même endroit. Le daily scrum (mêlée quotidienne) n’est pas une réunion de reporting où chacun justifie son emploi du temps, mais un moment d’inspection collective où l’équipe examine sa progression vers le sprint goal et ajuste son plan pour les prochaines vingt-quatre heures.
La formule classique des trois questions (“Qu’ai-je fait hier? Que vais-je faire aujourd’hui? Y a-t-il des obstacles?”) est un support courant, mais le Scrum Guide ne l’impose pas. Certaines équipes préfèrent parcourir le tableau des tâches de droite à gauche, en commençant par ce qui est proche de la finalisation. Ce qui compte, c’est que la conversation reste brève, quotidienne et centrée sur le sprint goal.
Lorsqu’un obstacle est identifié, le Scrum Master le note et facilite sa résolution, sans nécessairement le résoudre lui-même. Son rôle est de créer les conditions pour que l’équipe puisse avancer.
Le travail de développement
Entre les daily scrums, l’équipe travaille sur les items du sprint backlog. Le Scrum Guide ne prescrit aucune méthode de travail particulière: pair programming, revue de code, tests ou conception collaborative sont autant de pratiques que l’équipe choisit selon son contexte. Le sprint backlog évolue au fur et à mesure que l’équipe apprend en travaillant, car la décomposition initiale en tâches est rarement parfaite.
Un principe fondamental guide cette période: aucun changement ne doit mettre en péril le sprint goal. Le Product Owner peut clarifier le périmètre et l’équipe peut renégocier le contenu du sprint backlog, mais le sprint goal reste stable. Si les circonstances rendent le sprint goal obsolète, le Product Owner a le pouvoir d’annuler le sprint, une décision rare mais prévue par le framework.
Le backlog refinement en milieu de sprint
Le Scrum Guide recommande que l’équipe consacre environ 10% de son temps au backlog refinement (affinage du backlog), c’est-à-dire à la clarification, au découpage et à l’estimation des items qui seront candidats pour les prochains sprints. En pratique, cela représente deux ou trois sessions courtes réparties en milieu de sprint.
Ce travail préparatoire est souvent sous-estimé, et pourtant il conditionne la qualité du sprint planning suivant. Sans refinement régulier, l’équipe découvre les ambiguïtés et les dépendances au moment même où elle devrait planifier, ce qui allonge la séance et dégrade la fiabilité des engagements.
Le dernier jour: inspecter et adapter
Le sprint se termine par deux événements consécutifs qui servent des objectifs distincts.
La sprint review: confronter le travail au réel
La sprint review (revue de sprint) dure au maximum deux heures pour un sprint de deux semaines. L’équipe y présente l’incrément, c’est-à-dire la somme de tous les éléments terminés conformément à la Definition of Done (les critères de qualité que l’équipe s’est fixés). Les parties prenantes (stakeholders) y participent pour donner leur avis, poser des questions et contribuer à l’adaptation du product backlog.
Loin d’être une démonstration à sens unique, la sprint review est un moment de collaboration où l’équipe et les parties prenantes évaluent ensemble ce qui a été produit et ajustent la direction pour la suite. Un item “presque terminé” n’est pas présenté: il retourne dans le backlog pour le prochain sprint.
La sprint retrospective: améliorer le processus
La sprint retrospective (rétrospective) suit immédiatement la review. En une heure à une heure et demie, l’équipe s’interroge sur ses propres pratiques pour identifier ce qui a bien fonctionné, ce qui devrait changer et quelles améliorations concrètes intégrer dans le prochain sprint.
Le Scrum Guide insiste sur un point que de nombreuses équipes négligent: la rétrospective doit produire au moins une action d’amélioration, pas seulement des constats. Une équipe qui se contente de lister des irritants sans décider d’actions correctrices transforme la rétrospective en exercice de défoulement sans impact sur la performance.
Et le cycle recommence
Le sprint suivant démarre immédiatement après la rétrospective, sans temps mort, avec un nouveau sprint planning qui relance le cycle. Cette continuité est délibérée: elle installe un rythme prévisible qui structure le travail de l’équipe et donne aux parties prenantes des points de contact réguliers pour suivre l’avancement du produit.