Définir la durée d'un sprint

Lorsqu’on se lance dans le développement agile, une des premières questions à laquelle il faut répondre concerne la durée des itérations.

Il n’y a pas de réponse universelle, chaque projet est différent et doit définir sa façon de travailler. S’il existe un consensus de la communauté agile pour préconiser que toutes les itérations doivent être de même durée et qu’une itération est un bloc de temps fixé, il y a des variations sur la durée d’une itération.

Scrum recommandait, jusqu’à il y a quelques années, des sprints d’un mois. La pratique actuelle dans les développements avec Scrum, c’est moins : la plupart des projets ont des sprints de deux ou trois semaines.

Les critères à retenir pour définir la bonne durée sont :

  • L’implication des clients et utilisateurs – Il faut tenir compte de leur disponibilité à utiliser les versions partielles produites à la fin de chaque sprint.
  • Le coût supplémentaire engendré par le sprint – Un sprint ajoute du travail supplémentaire pour préparer le produit partiel, faire les tests de non-régression, préparer la démonstration pour la revue de fin de sprint.
  • La taille de l’équipe – Plus il y a de personnes dans l’équipe, plus il faudra de temps pour se synchroniser.
  • La durée maximum pour prendre en compte un changement – Il faut tenir compte du fait que cette durée peut aller jusqu’à deux fois la durée d’un sprint (le changement est demandé pendant l’itération n et développé au plus tôt dans l’itération n +1, dans le cas où l'équipe n'accepte pas d'être perturbée pendant le sprint par des urgences).
  • La date de fin de la release – La release devrait comporter au moins quatre sprints pour que l’équipe commence à bénéficier des avantages de l’itératif. Donc si la release dure deux mois, il est préférable d’avoir des sprints de deux semaines ou moins.
  • Le maintien de la motivation de l’équipe – Un sprint avec une durée trop longue est sujet à ne pas avoir une distribution uniforme du travail pendant l’itération ce qui conduit à travailler dans l’urgence à la fin.
  • La stabilité de l’architecture – Ce sera difficile d’obtenir un produit qui fonctionne dans une durée courte si l’architecture n’est pas stable.

Ce billet s'appuie sur un extrait du livre Scrum le guide pratique de la méthode agile la plus populaire, chapitre 6 La planification de release, pages 78 et 79.