Allez savoir pourquoi, la durée d’un sprint est un sujet qui vous préoccupe beaucoup.
Voyons ensemble les avantages et les inconvénients de chaque durée de sprint en se basant sur une échelle de durée de 1 à 4 semaines.
Pourquoi la durée compte ?
Avant de comprendre pourquoi avoir différentes durées de sprint, il faut rappeler l’objectif de travailler en sprint.
- La découpe en sprint permet de livrer plus rapidement quelque chose dans les mains de l’utilisateur.
A la fin d’un sprint, l’équipe doit pouvoir être en mesure de livrer quelque chose.
En ce sens, plus la durée d’un sprint est court, plus on peut imaginer que l’on livrera quelque chose de vite.
Oui, mais pas que…
Voyons cela en détail.
1 SEMAINE
Cette durée est vraiment adapté à des produits avec une faible technicité ou dans un phase de débugs.
En clair, pas de grosses fonctionnalités à livrer.
Avantages :
- Cycle de livraison poussé à l’extrême
- Gros focus de l’équipe, c’est presque du mono tâche.
Inconvénients :
- Pas facile de livrer quelque chose en 1 semaine
- Multiplication des cérémonies scrum. 1 sprint d’une semaine cela veut dire, beaucoup de bureaucratie
- 1 sprint planning par semaine
- Une review par semaine
- 1 rétrospective par semaine
2 SEMAINES
C’est clairement la durée la plus répandue dans l’univers scrum.
Pas trop long mais pas trop court, cette durée permet d’assurer une livraison pas trop petite à chaque fin de sprint et de garantir une cadence de livraison en cycle court.
Avantages :
- Bon équilibre entre valeur livrée à l’utilisateur et fréquence de livraison
Inconvénients :
- Aucun au niveau fonctionnel.
Si on choisit de ne pas l’utiliser c’est par choix de raccourcir ou allonger les cycles produit.
3 SEMAINES
Une durée de sprint qui commence à peser.
Cela peut être adapté dans certaines équipes qui ont une fonctionnalité qui nécessite une partie d’investigation et une partie d’implémentation.
Plutôt que de découper tout le process en 2 sprints, on fait tout en 1 seul sprint.
Avantages :
- Durée idéale pour livrer une fonctionnalité complexe en 1 fois
Inconvénients :
- Phase de test et de merge est plus complexe.
4 SEMAINES
Durée beaucoup trop longue en phase de maturité. Cela pénalise le cycle de livraison.
A ce stade si vos sprints font cette longueur, vos utilisateurs vont attendre pour avoir des nouveautés.
Au niveau du product owner, pas facile non plus d’alimenter une équipe en user stories pour 4 semaines.
Il faut beaucoup de travail en amont et cela nécessite des poker grooming et sprint planning assez gros.
Avantages :
- Convient à des projets en démarrage avant lancement quand on bosse en mode MVP et qu’il n’y a encore d’utilisateur. La pression de livraison est minime.
- Cela permet de pouvoir bosser sur de gros travaux et placer les fondamentaux.
Inconvénients :
- Augmentation de la charge de travail du PO pour préparer les sprints.
- Manque de lisibilité sur le suivi du sprint
- Phase de recette importante
- Cycle de livraison non agile
CONCLUSION
Je suis plutôt agnostique sur la durée du sprint.
Tout dépend de la phase produit et l’industrie dans lesquelles vous opérez.
Par exemple dans le BtoC, on a plus de pression a faire des releases fréquentes que dans le BtoB.
Dans le meilleur des mondes, il faudrait pouvoir adapter la durée de son sprint en fonction de la charge de travail disponible et des urgences à livrer.
Dans la réalité, on ne change pas la durée d’un sprint en cours d’année.
C’est certainement pour ces raisons que le sprint de 2 semaines est le plus populaire car il garantie une bonne moyenne de valeur et une bonne cadence de livraison tout au long de l’année.