Quelle est la durée idéale d’un sprint ?

Thibault Baheux

9 août 2022 - minutes de lecture

Le Scrum Guide nous dit qu'un sprint doit avoir une durée de 4 semaines maximum, tout en laissant à l'équipe Scrum la possibilité de s'organiser comme elle le souhaite.

Pour ceux qui n'ont pas l'habitude de travailler en mode agile, c'est perturbant. On ne sait pas vraiment par quel bout prendre le sujet. 

Vaut-il mieux avoir un sprint d'1 semaine ? De 2 ? De 4 ? Comment savoir faire la différence ? Et les sprints peuvent-ils avoir une durée variable ?

Je réponds à toutes vos interrogations dans l'article sur la durée des sprints.

Quelle est la durée idéale d'un sprint ?

La durée idéale d'un sprint est de 2 semaines. Un sprint d'1 semaine est trop court et ne donne pas suffisamment de temps pour avancer sur les user stories, alors qu'un sprint de 4 semaines est trop long, ce qui offre peu de place pour l'adaptation et l'amélioration continue.

Un sprint de 2 semaines est donc un bon compromis, qui permet à l'équipe d'avoir suffisamment de temps pour avancer sur le développement des récits utilisateurs, tout en pouvant échanger régulièrement en sprint review avec les parties prenantes, et obtenir du feedback.

En effet, prenons un projet de 6 mois. Avec des sprints de 4 semaines, l'équipe Scrum n'aurait que 6 sprints. Avec des sprints de 2 semaines, on multiplie par 2, ce qui laisse d'autant plus d'opportunités à l'équipe de s'améliorer et d'améliorer le produit.

Voici la durée des différents évènements Scrum pour un sprint de deux semaines :

Évènements Scrum

Sprint de 2 semaines

Sprint Planning

4 heures maximum

Daily Scrum

15 minutes quotidiennes

Sprint Review

2 heures maximum

Sprint Retrospective

1h30 maximum

Comment définir la bonne durée d'un sprint ?

Si vous souhaitez déterminer avec précision la meilleure durée pour vos sprints, voici les 8 critères dont vous devez tenir compte afin de définir la durée d'un sprint.

Pour faire simple, un sprint ne doit être ni trop long, ni trop court.

  1. La durée du projet.
    Pour tirer avantage de Scrum, l'équipe doit avoir plusieurs sprints afin de raccourcir le cycle d'apprentissage, de tester et valider des hypothèses, et de pratiquer l'empirisme. Prévoyez minimum une dizaine de sprints dans votre projet.
  2. L'implication des clients et des utilisateurs.
    Les utilisateurs finaux peuvent-ils se rendre disponibles pour chaque sprint review. Se réunir toutes les semaines peut vraiment être contraignant pour eux. Leur implication est indispensable pour la réussite du projet, tenez compte de leur disponibilité.
  3. La taille de l'équipe.
    Plus l'équipe projet est grande, plus il faudra de temps pour se synchroniser et apprendre à travailler ensemble. Essayez de garder une taille d'équipe inférieur à 7 personnes.
  4. La durée maximum pour prendre en compte un changement.
    Cette durée peut aller jusqu'à deux fois la durée d'un sprint. Si le changement est demandé lors de l'itération N, il pourra être pris en compte et développé lors de l'itération N+1 voire N+2.
  5. La date de fin de la release.
    La bonne pratique est d'avoir une release qui comporte au moins 4 sprints, pour bénéficier des avantages du cycle itératif. Ce point n'est pas indispensable, tout dépend de comment sont organisées vos releases dans le temps.
  6. Le maintien dans le temps de la motivation.
    Plus un sprint est long, plus il est compliqué de maintenir le niveau de motivation de l'équipe Scrum dans le temps.
  7. Le coût supplémentaire engendré par le sprint.
    Un sprint est rythmé par plusieurs évènements : sprint planning, sprint review et sprint retrospective. Chacun de ces évènements doit être préparé, ce qui demande du temps et représente un coût supplémentaire.
  8. L'incertitude.
    Plus un sprint est long, plus l'incertitude augmente, plus il y a de chances que le travail dérive, et plus il y a de chances que des erreurs se glissent dans les estimations agiles.

Peut-on changer la durée d'un sprint après l'avoir commencé ?

Une fois un sprint commencé, il n'est pas possible de modifier sa durée. La durée d'un sprint est généralement établie au début du projet agile, et ne change plus en cours de projet.

Changer en cours de route la durée du sprint signifie souvent :

  • Changer la definition of done.
    Modifier la durée du sprint, c'est faire des concessions sur la définition de fini. Ce serait accepter de baisser momentanément la qualité pour permettre certains changements de contenu. Ce n'est pas souhaitable.
  • Modifier le rythme des réunions et évènements.
    Un sprint commence dès la fin du précédent. Modifier la durée d'un sprint en cours de route revient à décaler toutes les réunions dans le temps. Ce sera d'autant plus compliqué pour impliquer les parties prenantes dans le projet.

Un sprint ne peut pas se terminer plus tôt que prévu

Si vous avez fini tout ce qui était prévu au sprint backlog, vous pouvez prendre en développement de nouvelles user stories du product backlog, ou en profiter pour travaillre sur les axes d'amélioration identifiés en rétrospective.

Un sprint ne peut pas se terminer plus tard que prévu

Si vous n'avez pas pu terminer tout ce qui était prévu au sprint backlog, ce n'est pas grave. C'est un enseignement pour les futurs sprints.

Pour rappel, l'équipe Scrum ne s'engage pas sur le développement de tous les éléments du sprint backlog. L'équipe s'engage sur l'atteinte de l'objectif de sprint, et sur la definition of done.

Tous les sprints doivent-ils avoir la même durée ?

Tous les sprints doivent avoir la même durée, selon le Scrum Guide. Ce sont des évènements d'une durée fixe, d'un mois ou moins, pour créer une cohérence. Lorsque vous décidez de la durée d'un sprint, cette durée sera la même durant tout le projet.

Cela permet ainsi à l'équipe Scrum :

  • D'avoir un rythme constant ET soutenable.
    En créant une routine reproductible de sprint en sprint, l'équipe adopte un rythme de travail constant. Elle est ainsi en mesure de livrer durablement du travail de qualité (les incréments), sans subir de coups de pression.
  • De se réunir à date et heure fixe.
    Tous les évènements sont connus à l'avance, ce qui permet à l'équipe de s'organiser plus facilement et de préparer efficacement chacun de ces évènements.
  • D'impliquer plus facilement les parties prenantes.
    Se réunir à date et heure fixe, d'itération en itération, permet d'impliquer plus facilement les parties prenantes. Si la sprint review a lieu le vendredi après-midi, le client et les utilisateurs feront le nécessaire pour se rendre disponible sur ce créneau.

Quel est le meilleur jour pour commencer un nouveau sprint ?

Le plus logique serait de commencer un nouveau sprint le Lundi, pour calquer le déroulé d'un sprint aux semaines d'un calendrier. Mais de nombreuses équipes ont souhaité démarrer leurs nouveaux sprints en milieu de semaine, comme le Mercredi.

Je vous explique dans cet article pourquoi démarrer un nouveau sprint le Lundi n'est pas la meilleure idée, et je passe en revue la totalité des jours ouvrés pour identifier le meilleur d'entre eux.


Thibault Baheux

Chef de projet IT depuis 2008, j'ai travaillé sur des projets à plusieurs millions d'euros.
J'ai décidé de dépoussiérer la gestion de projet.
Exit les méthodologies complexes, exit les outils lents, lourds, complexes à utiliser.
Mon objectif ? Vous donner les clés pour piloter vos projets avec efficacité.


Articles Similaires


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}