Qu'est-ce qu'un Sprint en agile ? Durée, événements et exemples

Qu'est-ce qu'un sprint en agile ?

A sprint est une période de durée fixe, d'un mois ou moins, durant laquelle une équipe agile travaille à un seul Sprint Goal et produit au moins un Increment utilisable du produit. Les sprints s'enchaînent sans interruption, et toutes les activités de planification, de coordination, de revue et d'amélioration du produit se déroulent en leur sein.

Le terme vient de Scrum, le cadre agile le plus utilisé. Le Scrum Guide (édition 2020, toujours la version officielle en vigueur) décrit les sprints comme le cœur battant de Scrum, là où les idées se transforment en valeur. D'autres méthodes agiles emploient le mot itération pour la même idée, et de nombreuses équipes qui ne suivent pas Scrum à la lettre parlent tout de même de « sprint ».

Quel que soit son nom, un sprint présente cinq caractéristiques déterminantes :

• Durée fixe. La durée est fixée à l'avance et reste la même d'un sprint à l'autre, ce qui permet à l'équipe de connaître son rythme.
• Un seul objectif. Chaque sprint a un Sprint Goal : un objectif unique qui explique pourquoi le sprint vaut la peine d'être mené.
• Un résultat utilisable. À la fin, l'équipe dispose d'un Increment qui satisfait la Definition of Done, même s'il n'est pas encore publié.
• Les uns après les autres. Un nouveau sprint commence immédiatement après la fin du précédent.
• Tout se passe à l'intérieur. La planification, la coordination quotidienne, l'affinage, la revue et la rétrospective ont toutes lieu pendant le sprint, ni avant ni après.

Ce sont les cycles courts et fixes qui rendent l'agilité empirique : toutes les quelques semaines, l'équipe et ses parties prenantes examinent un résultat réel et fonctionnel et décident de la suite.

Sprint vs itération vs Scrum

Ces termes sont souvent confondus. Le tableau montre comment ils s'articulent.

En résumé, un sprint est un type d'itération, et Scrum est le cadre qui fixe les règles du sprint. L'idée sous-jacente est le développement itératif et incrémental : construire le produit par petites tranches et l'améliorer à chaque cycle.

Quelle est la durée d'un sprint ?

Le Scrum Guide ne fixe qu'une seule règle : un sprint dure un mois ou moins. Dans cette limite, l'équipe choisit. En pratique, la plupart des équipes mènent des sprints d'une à quatre semaines, et deux semaines est de loin le choix le plus courant, car il équilibre la rapidité des retours et le coût de la planification et des revues.

Comment choisir la durée d'un sprint

Choisissez la durée la plus courte dans laquelle l'équipe peut livrer quelque chose de significatif et Done. Tenez compte ensuite des éléments suivants :

• La vitesse du changement. Plus le marché ou les exigences sont volatils, plus le sprint doit être court.
• Le délai acceptable pour les retours. Si les parties prenantes doivent voir l'avancement chaque semaine, un sprint de quatre semaines est trop long.
• La taille des éléments. Si la plupart des éléments du backlog prennent plus de quelques jours, découpez-les avant d'allonger le sprint.
• Les contraintes de mise en production et de test. L'intégration, les contrôles de conformité ou les délais d'approvisionnement matériel peuvent rendre les sprints très courts peu pratiques.
• L'alignement. Les équipes qui travaillent sur le même produit partagent généralement la même durée de sprint et la même date de début.

Changer la durée du sprint

Gardez une durée stable pendant au moins plusieurs sprints pour que votre vélocité et vos prévisions aient un sens. Changez-la de manière délibérée lors d'une rétrospective, pas en cours de sprint, et ne prolongez jamais un sprint parce que le travail n'est pas terminé. Pour les règles propres à Scrum, consultez notre guide du cycle du Sprint Scrum.

Les composantes d'un sprint

Trois éléments donnent sa forme à un sprint : un objectif, un plan et un résultat.

Sprint Goal

Le Sprint Goal est l'objectif unique du sprint. Il est créé pendant le Sprint Planning et constitue l'engagement des Developers. Un bon Sprint Goal décrit un résultat, pas une liste de tickets, ce qui laisse à l'équipe la latitude d'ajuster le travail détaillé à mesure qu'elle apprend.

• Faible : « Terminer les tickets 412, 415, 419 et 420. »
• Mieux : « Permettre aux clients récurrents de payer en une seule étape afin de vérifier si cela réduit les abandons de panier. »
• Exemple hors logiciel : « Lancer la page d'atterrissage de la campagne de printemps et les deux premiers e-mails pour que l'équipe commerciale puisse commencer la prospection lundi. »

Sprint Backlog

Le Sprint Backlog se compose du Sprint Goal, des éléments du Product Backlog sélectionnés pour le sprint et du plan des Developers pour les livrer. Il appartient aux Developers, qui le mettent à jour tout au long du sprint pour que chacun puisse voir le travail restant.

Increment et Definition of Done

Un Increment est une étape vers l'objectif produit, utilisable et conforme à la Definition of Done. Le travail qui ne satisfait pas la Definition of Done ne fait pas partie de l'Increment, aussi proche soit-il. Plusieurs Increments peuvent être créés au cours d'un sprint et publiés à tout moment ; la Sprint Review n'est pas un jalon de mise en production.

Les événements d'un sprint

Le sprint est un conteneur pour quatre autres événements. Les time-boxes ci-dessous sont les maximums indiqués par le Scrum Guide pour un sprint d'un mois ; pour des sprints plus courts, les événements sont généralement plus courts.

Sprint Planning ouvre le sprint. Le Product Owner explique quels objectifs comptent le plus, les Developers sélectionnent les éléments qu'ils pensent pouvoir terminer, et l'équipe élabore ensemble le Sprint Goal. Les Developers planifient ensuite la réalisation du travail, souvent en découpant les éléments en tâches d'une journée ou moins.

Le Daily Scrum est un point de 15 minutes pour les Developers. Ce n'est pas un compte rendu d'avancement destiné à un manager. La question essentielle est : sommes-nous en bonne voie pour atteindre le Sprint Goal, et que changeons-nous aujourd'hui si ce n'est pas le cas ?

La Sprint Review est une séance de travail, pas une présentation de diapositives. L'équipe montre ce qui est Done, les parties prenantes donnent leur avis et le groupe discute de la suite, ce qui met à jour le Product Backlog.

La Sprint Retrospective clôt le sprint. L'équipe choisit un petit nombre d'améliorations concrètes, et les plus importantes peuvent être ajoutées au Sprint Backlog suivant.

Affinage du backlog n'est pas un événement mais une activité continue pendant le sprint. L'équipe clarifie, découpe et dimensionne les éléments à venir pour que le prochain Sprint Planning se déroule rapidement.

Pour les ordres du jour et les conseils d'animation de chaque réunion, consultez notre guide des cérémonies Scrum.

Qui fait quoi dans un sprint

Une Scrum Team comporte trois responsabilités. Toutes trois sont nécessaires au bon fonctionnement d'un sprint.

Notez que personne n'attribue de tâches aux Developers ; ils organisent eux-mêmes le travail.

Comment planifier et mener un sprint, étape par étape

Voici la séquence que nous recommandons à une équipe qui mène ses premiers sprints. Elle suit le Scrum Guide, enrichie d'habitudes pratiques.

1. Préparez le Product Backlog. Avant la planification, assurez-vous que les premiers éléments sont ordonnés, clairs et assez petits pour être terminés dans le sprint. L'affinage du sprint précédent sert à cela.
2. Vérifiez la capacité. Recensez les congés, formations et autres engagements pour savoir de combien de temps l'équipe dispose réellement. Notre guide de la planification de capacité agile explique comment faire.
3. Convenez du Sprint Goal. Lors du Sprint Planning, le Product Owner propose l'objectif et l'équipe le formule en une phrase claire.
4. Sélectionnez le travail. Les Developers tirent les éléments du haut du backlog jusqu'à atteindre une charge réaliste, en s'appuyant sur la vélocité ou le débit récents.
5. Planifiez le comment. Découpez les premiers jours de travail en tâches et convenez de qui commence quoi. Il n'est pas nécessaire de planifier toutes les tâches à l'avance.
6. Travaillez par petits lots. Terminez les éléments avant d'en commencer de nouveaux. Quand quelqu'un est bloqué, les autres l'aident ; c'est ce qu'on appelle le swarming.
7. Inspectez chaque jour. Utilisez le Daily Scrum et un tableau Scrum visible pour repérer tôt les risques qui pèsent sur le Sprint Goal.
8. Affinez le travail à venir. Consacrez du temps à chaque sprint à préparer les éléments suivants ; les éditions antérieures du Scrum Guide indiquaient que cela ne prend généralement pas plus de 10 % de la capacité de l'équipe, et beaucoup d'équipes s'en servent encore comme règle empirique.
9. Faites la revue avec les parties prenantes. Montrez ce qui est Done, recueillez les retours et mettez à jour le Product Backlog.
10. Améliorez-vous. Tenez la rétrospective, choisissez une ou deux actions et reportez-les dans le sprint suivant, qui commence immédiatement.

Un modèle de sprint planning prêt à l'emploi vous offre un espace pour le Sprint Goal, la capacité, les éléments sélectionnés et les tâches.

Exemple : un sprint de deux semaines, jour après jour

Voici à quoi pourrait ressembler un sprint type de deux semaines pour une équipe produit de six personnes travaillant du lundi au vendredi. Les horaires sont indicatifs ; adaptez-les à votre propre calendrier.

Exemples de Sprint Goals

• Produit logiciel : « Les nouveaux utilisateurs peuvent s'inscrire avec une adresse e-mail professionnelle et inviter un collègue, afin que nous puissions lancer la bêta de l'onboarding. »
• Équipe marketing : « Publier la page d'atterrissage du webinaire et le parcours d'inscription afin d'ouvrir les inscriptions pour l'événement de juin. »
• Équipe RH : « Tester la nouvelle check-list d'intégration avec les deux nouvelles recrues qui arrivent ce mois-ci. »
• Informatique interne : « Faire passer l'équipe finance sur la nouvelle configuration d'ordinateurs portables sans perte d'accès aux lecteurs partagés. »

Peut-on modifier, prolonger ou annuler un sprint ?

Le Scrum Guide fixe des règles claires pour un sprint en cours :

• Aucun changement qui mette en danger le Sprint Goal. Un nouveau travail urgent peut être discuté, mais l'équipe protège l'objectif.
• La qualité ne baisse pas. La Definition of Done n'est pas assouplie pour tenir une date.
• Le périmètre peut être clarifié et renégocié avec le Product Owner à mesure que l'équipe en apprend davantage. Des éléments peuvent être échangés ou retirés tant que l'objectif tient toujours.
• Le Product Backlog est affiné selon les besoins.

Prolonger un sprint n'est pas autorisé. La time-box est fixe. Le travail qui n'est pas Done retourne dans le Product Backlog, où le Product Owner le réordonne ; il n'est pas automatiquement reporté au sprint suivant, et le travail partiel ne compte pas dans la vélocité.

Annuler un sprint est possible mais rare. Seul le Product Owner peut le faire, et uniquement si le Sprint Goal devient obsolète, par exemple parce que l'entreprise change de cap ou que le marché évolue. Tout travail Done fait l'objet d'une revue, et les éléments incomplets retournent dans le Product Backlog.

Si les parties prenantes continuent d'injecter du nouveau travail dans les sprints en cours, traitez-le comme une forme de dérive du périmètre : faites plutôt passer les demandes par le Product Owner et le Product Backlog.

Comment suivre l'avancement pendant un sprint

Vous n'avez pas besoin d'un reporting complexe pour gérer un sprint, mais vous devez voir si l'objectif est en bonne voie.

• Tableau Scrum ou Kanban. Des colonnes telles que À faire, En cours, En revue et Terminé montrent le travail d'un coup d'œil et rendent les goulots d'étranglement visibles.
• Sprint burndown chart. Représente le travail restant chaque jour par rapport à une ligne idéale. Une courbe plate pendant plusieurs jours est un signal d'alerte précoce.
• Vérification du Sprint Goal. À chaque Daily Scrum, demandez-vous si l'objectif est toujours atteignable ; c'est plus important que n'importe quel graphique.
• Vélocité ou débit (après le sprint). La quantité de travail terminée par sprint, utilisée pour planifier les sprints suivants. Voir Graphiques de vélocité agile.
• Taux d'atteinte du Sprint Goal. Sur plusieurs sprints, la fréquence à laquelle l'équipe atteint son objectif est une mesure utile de sa prévisibilité.

Quoi que vous suiviez, utilisez-le pour aider l'équipe à s'adapter, pas pour comparer les équipes ou les individus.

Les avantages du travail en sprints

• Des retours rapides. Les parties prenantes voient des résultats fonctionnels toutes les quelques semaines plutôt qu'à la fin du projet.
• La concentration. Un objectif unique et un horizon court réduisent le multitâche et les changements de contexte.
• Un risque réduit. Les problèmes apparaissent en l'espace d'un sprint, lorsqu'ils sont moins coûteux à corriger.
• La prévisibilité. Une cadence régulière facilite les prévisions et la planification des releases.
• L'amélioration intégrée. La rétrospective offre à l'équipe un temps régulier et protégé pour améliorer sa façon de travailler.
• Transparence. Les objectifs, les backlogs et les tableaux rendent l'avancement visible pour tous.

Erreurs courantes en sprint et comment les corriger

Toutes les équipes agiles utilisent-elles des sprints ?

Non. Les sprints appartiennent à Scrum et aux méthodes fondées sur des itérations comme XP et SAFe. D'autres approches fonctionnent différemment :

• Kanban utilise un flux continu avec des limites de travail en cours au lieu de sprints fixes ; la planification et les mises en production ont lieu quand c'est nécessaire. Comparez-les dans Kanban vs Scrum.
• Scrumban combine les deux, en conservant souvent une cadence de planification tout en gérant le travail comme un flux.
• Les design sprints sont une autre idée : un atelier structuré d'environ cinq jours (popularisé par Google Ventures) pour explorer et tester un concept de produit. Il partage le nom mais pas les règles de Scrum.

Pour comparer ces approches, lisez types de méthodes agiles.

Modèles et outils de sprint

Vous pouvez mener des sprints avec des post-it et un tableau blanc, mais les modèles et logiciels facilitent le partage du travail, surtout pour les équipes à distance.

• Modèle de Sprint Planning : Sprint Goal, capacité, éléments sélectionnés, estimations et tâches.
• Modèle de Sprint Retrospective : ce qui a bien fonctionné, ce qu'il faut améliorer et les actions.
• Modèle de Product Backlog : une liste ordonnée d'éléments prêts pour les sprints à venir.
• Modèle de user story : des user stories homogènes avec critères d'acceptation et estimations.
• Modèle de plan de projet agile : releases, sprints et jalons dans une seule vue.

La plupart des outils de gestion de projet prennent désormais en charge les sprints. Jira est conçu autour des tableaux Scrum et Kanban pour les équipes logicielles, tandis que Wrike, notre outil le mieux noté, convient aux équipes qui mènent des sprints en parallèle d'autres types de travaux dans plusieurs services.

Modèles gratuits sur ce sujet

Parcourir tous les modèles

Questions fréquentes