Le Sprint est le cœur battant du framework Scrum : un événement à durée fixe pendant lequel le Scrum Team transforme une sélection du Product Backlog en un Increment utilisable. Ce guide complet rassemble tout ce qu'il faut savoir sur le Sprint Scrum — définition officielle, déroulement, Sprint Planning, Sprint Review, Sprint Retrospective, Sprint Backlog, Sprint Goal, exemples concrets, bonnes pratiques, erreurs fréquentes et questions PSM I — pour devenir la référence francophone sur le sujet.
Qu'est-ce qu'un Sprint ?
Un Sprint est une itération courte, à durée fixe, qui constitue l'unité de base du framework Scrum. Pendant un Sprint, l'ensemble du Scrum Team — Product Owner, Scrum Master, Developers — collabore pour livrer un Increment de produit utilisable et porteur de valeur. La sprint définitionretenue dans le Scrum Guide est volontairement brève : « Sprints are the heartbeat of Scrum, where ideas are turned into value ».
Le sprint agile ne se confond pas avec une simple itération. Il impose une structure claire : un Sprint Goal unique, un Sprint Backlog construit par les Developers, une Definition of Done partagée, et la tenue obligatoire des quatre autres événements Scrum. C'est cette structure qui permet la transparence, l'inspection et l'adaptation, les trois piliers de l'empirisme dans le sprint framework Scrum.
Pour un candidat au PSM I, comprendre le Sprint dans son ensemble est plus important que de mémoriser des phrases isolées. Le scrum sprintn'est pas une « phase de développement » : c'est un mini-cycle complet Plan → Build → Inspect → Adapt qui ramène le Scrum Team à zéro à intervalles réguliers.
Définition officielle du Scrum Guide
Le Scrum Guide 2020 (Ken Schwaber & Jeff Sutherland) décrit le Sprint comme suit (traduction libre, fidèle à l'esprit du texte officiel) :
« Les Sprints sont le rythme cardiaque de Scrum, là où les idées sont transformées en valeur. Ils ont une durée fixe d'un mois ou moins, pour garantir la cohérence. Un nouveau Sprint commence immédiatement à la conclusion du précédent. Tout le travail nécessaire pour atteindre le Product Goal, y compris le Sprint Planning, les Daily Scrums, la Sprint Review et la Sprint Retrospective, se produit dans les Sprints. »
Quatre éléments clés se dégagent de cette définition officielle :
- Cadence régulière : la durée reste stable d'un Sprint à l'autre.
- Durée maximale : un mois calendaire, jamais davantage.
- Continuité : pas de pause entre deux Sprints.
- Conteneur d'événements : Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective sont tous des sous-événements du Sprint.
Le sprint scrum est donc à la fois un événement (avec sa propre timebox) et un cadre qui englobe les autres événements. Cette dualité est souvent source de confusion pour les débutants ; nous y reviendrons dans la section Cycle de vie d'un Sprint.
Objectifs d'un Sprint
Un Sprint poursuit trois objectifs simultanés : produire de la valeur, apprendre, et créer de la prévisibilité. Plus précisément, chaque Sprint cherche à :
- Atteindre un Sprint Goal formulé par le Scrum Team au Sprint Planning, qui donne le « pourquoi » du Sprint.
- Produire un Increment respectant la Definition of Done, c'est-à-dire utilisable et potentiellement livrable.
- Inspecter et adapter le produit (Sprint Review) et la manière de travailler (Sprint Retrospective).
- Réduire le risque : au pire, un Sprint perdu ne coûte qu'un Sprint, jamais davantage.
- Maintenir un rythme soutenable qui permette la collaboration et la qualité dans la durée.
En SEO comme dans la vraie vie, le terme sprint planningcapte beaucoup de recherches, mais il ne faut pas confondre le Sprint (l'itération entière) avec le Sprint Planning (l'événement de cadrage initial). Le pilier Sprint Planning détaille cet événement spécifique.
Durée d'un Sprint
La sprint définition officielle fixe une borne haute : un mois calendaire. Au-delà, on sort du framework Scrum. En pratique, les équipes choisissent une durée comprise entre une et quatre semaines :
| Durée | Avantages | Inconvénients |
|---|---|---|
| 1 semaine | Feedback ultra-rapide ; risque minimal ; idéal pour produits volatils. | Overhead des événements (planning, review, retro) élevé proportionnellement. |
| 2 semaines | Standard de marché ; bon équilibre rythme / overhead ; compatible avec la plupart des contextes. | Peut être court pour des items techniques complexes mal raffinés. |
| 3 semaines | Plus de marge pour les items techniques. | Cadence plus lente, feedback plus tardif. |
| 4 semaines (1 mois) | Maximum autorisé ; utile pour produits matures et stables. | Risque accru ; difficile de pivoter. |
Une fois choisie, la durée doit rester stable. Changer de durée tous les deux Sprints empêche toute mesure de vélocité, perturbe le rythme du Scrum Team et brouille la lecture des stakeholders. Si vous devez ajuster la durée, faites-le en Sprint Retrospective, de manière intentionnelle et durable.
Pourquoi un Sprint est-il time-boxé ?
La time-box est une contrainte structurelle, pas une commodité de planning. Elle remplit cinq fonctions :
- Forcer la décision : faute de temps illimité, le Scrum Team doit trancher et avancer.
- Limiter le risque : au pire, on perd la valeur d'un Sprint, jamais davantage.
- Créer un rythme : la cadence régulière nourrit la prévisibilité et la confiance des stakeholders.
- Favoriser l'apprentissage : on inspecte et on adapte à chaque fin de Sprint.
- Protéger la concentration : la time-box rend explicite ce qui rentre… et ce qui n'entre pas.
Une time-box n'est pas une cible mais une limite supérieure. Une Sprint Review qui s'achève au bout de 45 minutes au lieu de 2 heures n'est pas anormale ; ce qui le serait, c'est qu'elle déborde sa timebox.
Sprint vs projet classique
Le Sprint diffère radicalement d'une phase de projet en cycle en V ou en waterfall. Ce n'est pas une « étape de développement » suivie d'une « étape de tests » : c'est un mini-cycle complet, autonome, qui livre de la valeur.
| Critère | Sprint Scrum | Phase de projet classique |
|---|---|---|
| Durée | Fixe, ≤ 1 mois. | Variable, fixée par un planning prévisionnel. |
| Livrable | Un Increment utilisable. | Un livrable intermédiaire (specs, dev, recette). |
| Engagement | Sprint Goal partagé par tout le Scrum Team. | Charge à produire selon le PMP / PRINCE2. |
| Adaptation | Au minimum à chaque fin de Sprint. | Souvent en fin de projet, parfois jamais. |
| Risque | Limité à la valeur d'un Sprint. | Cumulatif jusqu'à la livraison finale. |
| Mesure | Increment livré, valeur observable. | Conformité au plan, jalons franchis. |
Cette différence explique pourquoi adopter Scrum sans repenser la culture de pilotage produit fonctionne rarement : on hérite alors d'« itérations en V » qui n'apportent ni la prévisibilité du waterfall, ni l'adaptabilité du Sprint.
Le Sprint Goal
Le sprint goal est le « pourquoi » du Sprint : un objectif unique, cohérent, qui donne du sens à la sélection d'items du Product Backlog. Il est défini collaborativement par le Scrum Team pendant le Sprint Planning et reste stable jusqu'à la fin du Sprint.
Le Sprint Goal est un commitment (engagement) attaché au Sprint Backlog, au même titre que le Product Goal est l'engagement du Product Backlog et la Definition of Done celui de l'Increment. Sans Sprint Goal, le Sprint Backlog n'est qu'une liste de tâches : avec lui, il devient un plan cohérent au service d'une valeur claire.
Le guide dédié Sprint Goal couvre la formulation, les pièges PSM I et de nombreux exemples concrets.
Exemples de Sprint Goal
- « Permettre à un client de payer une commande sans créer de compte. »
- « Réduire de 30 % le temps de chargement de la page d'accueil. »
- « Valider auprès de 5 utilisateurs pilotes le parcours de réservation mobile. »
Un bon Sprint Goal est court, orienté valeur, mesurable et indépendant des items choisis : si l'équipe découvre une meilleure manière d'atteindre le but, elle peut adapter le Sprint Backlog sans renégocier le Sprint Goal.
Sprint Planning
Le sprint planning est le premier événement du Sprint. Il donne le coup d'envoi : timebox de 8 heures maximum pour un Sprint d'un mois (proratiser pour les Sprints plus courts : 4 h pour 2 semaines, 2 h pour 1 semaine). Tout le Scrum Team y participe : Product Owner, Developers, Scrum Master.
Le Sprint Planning répond à trois questions, dans cet ordre :
- Pourquoi ce Sprint est-il précieux ? → Sprint Goal.
- Que peut-on faire pendant ce Sprint ? → sélection des Product Backlog Items.
- Comment le travail sera-t-il réalisé ? → plan de livraison construit par les Developers.
Le résultat est un Sprint Backlog cohérent : Sprint Goal + items sélectionnés + plan pour les livrer.
Pour aller plus loin, le pilier complet Sprint Planning et son satellite Sprint Planning Template proposent un agenda type, des modèles Markdown / Excel / Google Sheets et un exemple détaillé.
Daily Scrum
Le Daily Scrum est l'événement quotidien des Developers : 15 minutes, même heure, même endroit, focalisé sur la progression vers le Sprint Goal. Ce n'est pas une réunion de statut : c'est un événement d'inspection et d'adaptation du plan, où les Developers ajustent leur Sprint Backlog pour les prochaines 24 heures.
- Pour qui ? Les Developers. Le Scrum Master et le Product Owner peuvent assister mais n'ont pas à parler s'ils ne sont pas Developers.
- Combien de temps ? 15 minutes, jamais plus. La time-box est stricte.
- Quel objectif ? Adapter le Sprint Backlog pour rester aligné avec le Sprint Goal.
Le guide pilier Daily Scrum détaille les formats classiques, les pièges PSM I et les bonnes pratiques pour les équipes distribuées.
Sprint Review
La sprint review est l'événement d'inspection de l'Increment. Le Scrum Team présente ce qui a été produit aux stakeholders et collecte leur feedback pour adapter le Product Backlog. Timebox : 4 heures pour un Sprint d'un mois, à proratiser.
- Inspection collective de l'Increment.
- Mise à jour du Product Backlog en direct.
- Discussion sur l'avancée vers le Product Goal.
- Décisions sur la suite : prochains Sprints, releases.
La Sprint Review n'est pas une démonstration commerciale ni une release : c'est un atelier de travail. Le guide pilier Sprint Review et son satellite Sprint Review Template proposent un modèle d'ordre du jour, un exemple complet et une checklist.
Sprint Retrospective
La sprint retrospective est le dernier événement du Sprint : le Scrum Team inspecte ses personnes, ses interactions, ses processus, ses outils et sa Definition of Done. Timebox : 3 heures pour un Sprint d'un mois. Au moins une amélioration concrète doit être intégrée au prochain Sprint Backlog.
La retrospective n'est pas un défouloir, ni un audit, ni un moment réservé au Scrum Master. C'est un événement de toute l'équipe pour augmenter sa qualité et son efficacité. Le guide pilier Sprint Retrospective détaille les formats, l'animation et les questions PSM I associées.
Sprint Backlog
Le sprint backlog est l'artefact construit par les Developers au Sprint Planning. Il combine trois éléments :
- Le Sprint Goal (engagement attaché au Sprint Backlog).
- Les Product Backlog Items sélectionnés pour le Sprint.
- Le plan élaboré pour livrer ces items et atteindre le Sprint Goal.
Le Sprint Backlog est la propriété des Developers : eux seuls décident de ce qu'il contient. Il est vivant : il évolue tout au long du Sprint à mesure que les Developers en apprennent davantage. Il doit être suffisamment détaillé pour que la progression puisse être inspectée chaque jour au Daily Scrum.
Exemple simplifié de Sprint Backlog
| Item | Estimation | Owner | Statut |
|---|---|---|---|
| Permettre le paiement invité | 8 pts | Alice | En cours |
| API de calcul des frais de port | 5 pts | Bruno | À faire |
| Refonte du tunnel mobile | 13 pts | Camille | En revue |
| Tests E2E parcours invité | 3 pts | Alice | Done |
Product Backlog
Le Product Backlog est la source unique de travail pour le Scrum Team. C'est une liste ordonnée, vivante, des fonctionnalités, évolutions, corrections et améliorations à apporter au produit. Le Product Owner en est responsable : ordonnancement, contenu, transparence.
Pendant le Sprint Planning, les Developers « tirent » des items du Product Backlog pour bâtir leur Sprint Backlog. Le Product Backlog continue d'évoluer pendant le Sprint via le refinement : ajout, ajustement, décomposition d'items.
Pour une plongée complète : Product Backlog — guide complet.
Increment
L'Increment est l'artefact « sortie » du Sprint : un palier concret vers le Product Goal. Chaque Product Backlog Item qui satisfait la Definition of Done est un Increment. Un Sprint peut donc produire plusieurs Increments — qui peuvent même être livrés aux utilisateurs avant la fin du Sprint.
Un Increment doit être utilisable. La Definition of Done garantit ce niveau de qualité minimal. Sans Definition of Done partagée, parler d'Increment n'a pas de sens : on a au mieux du travail en cours.
Le guide pilier Increment Scrum détaille cette notion centrale.
Déroulement complet d'un Sprint (chronologie illustrée)
Pour rendre concret le scrum sprint, voici la chronologie type d'un Sprint de 2 semaines (10 jours ouvrés). Chaque équipe ajuste à son contexte, mais les grandes étapes restent les mêmes.
- 1J1 matin — Sprint PlanningLe Scrum Team définit le Sprint Goal, sélectionne les Product Backlog Items et bâtit le Sprint Backlog.
- 2J1 → J9 — Travail quotidien + Daily ScrumLes Developers livrent un ou plusieurs Increments. Le Daily Scrum (15 min) inspecte la progression vers le Sprint Goal.
- 3J5 — Refinement (optionnel)Le Scrum Team raffine en continu le Product Backlog pour les Sprints suivants.
- 4J10 matin — Sprint ReviewInspection de l'Increment avec les stakeholders, adaptation du Product Backlog.
- 5J10 après-midi — Sprint RetrospectiveInspection des personnes, interactions, processus et outils ; au moins une amélioration intégrée au prochain Sprint.
Notez que le refinement n'est pas un événement formel : c'est une activité continue qui peut occuper jusqu'à 10 % de la capacité du Scrum Team. Le bon dosage permet d'arriver en Sprint Planning avec un Product Backlog propre et un Sprint Goal candidat clair.
Cycle de vie d'un Sprint
Le cycle de vie d'un Sprint suit toujours la même séquence :
- Sprint Planning : Sprint Goal, sélection d'items, plan.
- Exécution : Developers livrent, Daily Scrum quotidien, refinement en continu, communication permanente avec le Product Owner.
- Sprint Review : inspection de l'Increment, adaptation du Product Backlog.
- Sprint Retrospective : inspection des pratiques, plan d'amélioration.
- Démarrage immédiat du Sprint suivant.
Ce cycle est immuable. Aucune phase intercalaire n'est prévue : pas de « sprint zéro », pas de « sprint de hardening », pas de « release sprint » au sens du Scrum Guide. Les équipes qui en ressentent le besoin doivent inspecter leur Definition of Done et leur refinement.
Bonnes pratiques
- Stabiliser la durée du Sprint pendant au moins 4 à 6 Sprints avant d'envisager un changement.
- Définir collectivement le Sprint Goal en début de Sprint Planning, pas après avoir sélectionné les items.
- Limiter le « work in progress » : peu d'items en cours en parallèle, beaucoup d'items Done.
- Faire évoluer la Definition of Done en Sprint Retrospective dès que l'équipe en est capable.
- Inviter les stakeholders à la Sprint Review : sans eux, il n'y a pas d'inspection significative.
- Respecter strictement les timeboxes : terminer tôt est sain, dépasser est interdit.
- Documenter légèrement : un Sprint Backlog clair vaut mieux qu'un PowerPoint riche.
Erreurs fréquentes
- Changer la durée du Sprint de manière opportuniste : impossible de mesurer quoi que ce soit.
- Sprint Goal flou ou absent : le Sprint devient une simple liste de tickets sans cohérence.
- Pas de Definition of Done partagée : pas d'Increment, pas d'inspection possible.
- Sprint Review = démo commerciale : on perd l'opportunité d'adapter le Product Backlog.
- Retrospective ignorée ou expédiée : pas d'amélioration continue.
- Prolonger le Sprint : interdit par le Scrum Guide.
- Ajouter des items « urgents » du management en plein Sprint sans renégociation avec le Product Owner.
- Confondre Sprint et release : un Increment peut être livré à tout moment, sans attendre la fin du Sprint.
Conseils pour réussir un Sprint
- Arriver préparé au Sprint Planning : Product Backlog raffiné, Sprint Goal candidat, capacité estimée.
- Verbaliser le Sprint Goal chaque jour au Daily Scrum.
- Faire vivre le Sprint Backlog : update permanent par les Developers.
- Livrer dès que possible : un Increment qui sort à J5 vaut mieux qu'un Increment qui sort à J10.
- Inviter les bons stakeholders à la Sprint Review (utilisateurs, sponsors, métier).
- Choisir une amélioration actionable à chaque Retrospective.
- Mesurer ce qui compte : valeur livrée, satisfaction utilisateur, dette technique — pas juste la vélocité.
Exemples concrets
Exemple 1 — Équipe e-commerce, Sprint de 2 semaines
Sprint Goal : « Permettre aux nouveaux clients de finaliser une commande sans créer de compte. » Le Sprint Backlog regroupe les items UI tunnel invité, API session anonyme, et tests E2E. La Sprint Review montre le parcours complet à 6 utilisateurs pilotes et 3 stakeholders métier. Résultat : 4 conversions sur 6 et 12 améliorations identifiées qui rejoignent le Product Backlog.
Exemple 2 — Équipe data, Sprint de 1 semaine
Sprint Goal : « Livrer un tableau de bord churnmensuel fiable pour le COMEX du 15. » Sprint Backlog : pipeline ETL, nettoyage des données, dashboard Superset. L'Increment livré inclut le dashboard et la procédure de mise à jour mensuelle. La Sprint Retrospective décide d'automatiser le refresh quotidien dès le Sprint suivant.
Exemple 3 — Équipe plateforme, Sprint de 3 semaines
Sprint Goal : « Réduire de 50 % le temps de build de la CI/CD. » Sprint Backlog : caching distribué, parallélisation des tests, refactor du pipeline. La Sprint Review présente les métriques avant / après et la Sprint Retrospective décide de pérenniser un atelier mensuel d'inspection des performances de la plateforme.
Tableau récapitulatif des événements et artefacts
| Élément | Type | Timebox / fréquence | Propriétaire |
|---|---|---|---|
| Sprint | Événement conteneur | ≤ 1 mois | Scrum Team |
| Sprint Planning | Événement | ≤ 8 h (Sprint d'1 mois) | Scrum Team |
| Daily Scrum | Événement | 15 min / jour | Developers |
| Sprint Review | Événement | ≤ 4 h (Sprint d'1 mois) | Scrum Team + stakeholders |
| Sprint Retrospective | Événement | ≤ 3 h (Sprint d'1 mois) | Scrum Team |
| Product Backlog | Artefact | Permanent | Product Owner |
| Sprint Backlog | Artefact | Le temps du Sprint | Developers |
| Increment | Artefact | Produit pendant le Sprint | Scrum Team |
| Product Goal | Engagement | Long terme | Product Owner |
| Sprint Goal | Engagement | Le temps du Sprint | Scrum Team |
| Definition of Done | Engagement | Permanent | Developers (cadre organisationnel possible) |
FAQ — questions fréquentes
Retrouvez ci-dessous, dans la section FAQ structurée de la page, les réponses aux douze questions les plus posées sur le Sprint Scrum.
Questions PSM I fréquentes
Le Sprint est l'un des thèmes les plus présents au PSM I. Quelques pièges classiques :
- Qui peut annuler un Sprint ? Le Product Owner, et lui seul, si le Sprint Goal devient obsolète.
- Que se passe-t-il si le Sprint Goal n'est pas atteint ? Le Sprint se termine quand même ; pas de prolongation.
- Combien d'Increments un Sprint produit-il ? Au moins un, potentiellement plusieurs, livrables à tout moment.
- Le Daily Scrum est-il pour le Scrum Master ? Non, c'est l'événement des Developers.
- Peut-on ajouter du travail pendant le Sprint ? Oui, en renégociant avec le Product Owner, tant que cela ne met pas en péril le Sprint Goal.
- Le Sprint contient-il la Sprint Retrospective ? Oui, le Sprint englobe les cinq événements (lui-même + les quatre autres).
- Peut-on changer la durée du Sprint ? Oui, mais cela doit être une décision durable, prise en Sprint Retrospective.
Résumé à retenir
Conclusion
Maîtriser le Sprint Scrum, c'est comprendre comment les cinq événements (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), les trois artefacts (Product Backlog, Sprint Backlog, Increment) et les trois engagements (Product Goal, Sprint Goal, Definition of Done) s'imbriquent pour produire de la valeur de manière régulière et soutenable.
Cette page pilier est conçue pour devenir votre point d'entrée vers l'ensemble du sprint framework Scrum. À mesure que vous explorerez les guides satellites (Sprint Planning, Sprint Review, Sprint Goal, Sprint Backlog, Increment…), revenez ici pour reconnecter chaque concept au cycle complet du Sprint.
À lire aussi
Source officielle : Scrum Guide 2020.