La réponse citée du Scrum Guide (pas plus d'un mois calendaire) pourrait ne pas être suffisante.
La vraie réponse est : cela dépend...
D'abord, vous devez considérer la capacité de votre organisation à planifier - l'horizon de planification.
Par exemple, si vous avez des Sprints de 2 semaines, il serait bon que l'horizon de planification de votre organisation soit quelque part autour de 4 semaines.
Ce que je veux dire par là, c'est que si une nouvelle idée est née pendant le premier Sprint et qu'elle n'est pas si urgente que vous devez annuler le Sprint (votre objectif actuel du Sprint est devenu non pertinent), alors posez la question de savoir si votre organisation est capable d'attendre jusqu'à 4 semaines -1 jour (en supposant, que cette idée est née le premier jour du premier Sprint) avec la réception de cette fonctionnalité faite ? Si c'est le cas et que vous n'avez pas besoin de changer l'objectif du sprint pour le moment, alors un sprint de deux semaines devrait être suffisant. Bien sûr, il peut y avoir des exceptions une fois tous les quelques sprints lorsque les changements sont vraiment urgents et que vous devez replanifier votre travail - mais les exceptions ne devraient pas se produire dans tous les sprints. Si cela ne va pas, alors essayez un Sprint d'une semaine.
Scrum favorise un rythme durable. Nous prenons une partie de l'environnement très chaotique de développement de projet/produit et nous le mettons dans une boîte magique et paisible appelée Sprint où la portée pourrait changer mais l'objectif principal devrait rester le même.
Alors, en choisissant la longueur du Sprint, essayez de penser à la façon dont votre organisation est bonne en matière de planification. Cela ne signifie pas que vous ne devriez pas coacher/enseigner votre organisation dans une meilleure planification si elle change tout le temps. Cela signifie seulement que vous devriez considérer cela avant de commencer à faire quelque chose qui sera inacceptable pour votre organisation et qui aura pour conséquence de rejeter Scrum avant même qu'il ne commence vraiment à fonctionner.
Chez Pragmatic Coders, nous travaillons généralement par itération de 2 semaines, mais dans certains projets, nous n'utilisons pas du tout Scrum. Le kanban avec un WIP limité fonctionne mieux dans certains cas.
.