Quelle devrait être la durée d'un sprint? Un guide clair pour choisir la bonne cadence
L'une des premières décisions que prend une nouvelle équipe Scrum est aussi l'une des plus discrètement déterminantes : quelle devrait être la durée d'un sprint? Le Guide Scrum est volontairement souple sur ce point. Il précise qu'un sprint est un événement de durée fixe d'un mois ou moins, et que des sprints plus courts génèrent plus de cycles d'apprentissage et limitent le risque à une fenêtre de coût et d'effort plus restreinte. Au-delà, le choix vous appartient. Cette liberté peut sembler être un piège quand on débute; il est donc utile de comprendre ce que l'on met réellement en balance.
Voyez le sprint comme le battement de cœur de votre livraison. Tout le reste, la planification, la mêlée quotidienne, la revue et la rétrospective, bat à son rythme. Un battement plus court signifie que vous inspectez et adaptez plus souvent. Un battement plus long vous laisse plus d'espace ininterrompu pour bâtir avant de vous arrêter pour vérifier le cap. Aucun n'est vertueux en soi; la bonne durée est celle qui fait remonter les problèmes assez vite pour les corriger sans épuiser l'équipe sous le poids des cérémonies.
Ce que la durée du sprint contrôle réellement
Quand les équipes débattent entre une semaine et deux, elles débattent en réalité de quatre choses sous le calendrier.
Fréquence de rétroaction. Un sprint court met un incrément fonctionnel devant les parties prenantes plus tôt et plus souvent. Si vos exigences sont floues ou changeantes, cette rétroaction fréquente vaut beaucoup.
Exposition au risque. Le Guide Scrum présente le sprint comme l'investissement maximal que vous acceptez avant de vérifier si vous bâtissez encore la bonne chose. Un sprint de deux semaines plafonne à deux semaines votre risque de mauvaise direction.
Charge des cérémonies. La planification, la revue et la rétrospective reviennent à chaque sprint. Sur une cadence d'une semaine, ces événements grugent une plus grande part de la semaine, ce qui peut frustrer les équipes dont le travail ne se découpe pas naturellement aussi petit.
Prévisibilité. Des sprints plus courts et plus fréquents donnent plus de points de données plus tôt, de sorte qu'une vélocité stable et une prévision utilisable émergent plus vite.
Une façon pratique de choisir
Pour la plupart des équipes qui débutent avec Scrum, deux semaines constituent un point de départ raisonnable. C'est assez court pour imposer une inspection régulière, assez long pour livrer quelque chose de significatif, et cela s'accommode bien des jours fériés et de l'absence occasionnelle pour maladie. Traitez cela comme une hypothèse à tester, non comme un engagement permanent, et réexaminez-le en rétrospective une fois quelques sprints réalisés.
Optez pour un sprint plus court (une semaine) lorsque les exigences changent sans cesse, que le domaine est nouveau pour l'équipe ou que les parties prenantes ont besoin de voir des progrès fréquents pour rester en confiance.
Optez pour un sprint plus long (trois à quatre semaines) uniquement lorsque le travail comporte un véritable coût de mise en place à chaque cycle, que les dépendances sont lentes et que des cérémonies fréquentes créeraient plus de friction que de valeur.
Gardez la durée constante. Résistez à la tentation d'étirer un sprint pour terminer du travail non planifié; cela efface discrètement la cadence qui fait fonctionner Scrum.
La période de reprise après la pandémie a donné à bien des équipes une nouvelle raison de privilégier des cycles plus courts. Avec des équipes hybrides et entièrement à distance, des priorités mouvantes et des perturbations d'approvisionnement encore présentes dans les plans, une boucle de rétroaction plus serrée facilitait la détection d'une hypothèse erronée avant qu'elle ne devienne coûteuse. Si votre environnement est volatil, penchez vers le court. La stabilité vous donne le droit à un rythme légèrement plus long.
Quel que soit votre choix, tenez-vous-y assez longtemps pour en tirer des leçons. Une cadence fixe vise la constance, et l'inspecter en rétrospective vise l'ajustement honnête. Choisissez une durée, réalisez plusieurs sprints, observez les données et l'énergie de l'équipe, puis modifiez de façon délibérée plutôt que réactive.
Si vous mettez en place une livraison agile pour la première fois et souhaitez de l'aide pour établir une cadence qui tient sous la pression du réel, le conseil en réalisation de programmes et de projets de XNM peut vous aider à bien faire dès le départ.