La respuesta citada de la Guía de Scrum (no más de un mes de calendario) podría no ser suficiente.
La verdadera respuesta es: depende...
En primer lugar hay que considerar la capacidad de su organización para planificar - horizonte de planificación.
Por ejemplo, si tienes Sprints de 2 semanas de duración, sería bueno que el horizonte de planificación de tu organización fuera de unas 4 semanas.
Lo que quiero decir con esto es que si alguna nueva idea nace durante el primer Sprint y no es tan urgente como para que tengas que cancelar el Sprint (tu objetivo actual del Sprint se volvió irrelevante) entonces hazte la pregunta de si tu organización es capaz de esperar hasta 4 semanas -1 día (asumiendo que esa idea nació en el primer día del primer Sprint) con recibir esta característica hecha. Si está bien y no tienes que cambiar el Objetivo del Sprint por el momento, entonces un Sprint de dos semanas debería ser suficiente. Por supuesto, puede haber algunas excepciones una vez cada pocos Sprints cuando los cambios son realmente urgentes y hay que volver a planificar el trabajo - pero las excepciones no deben ocurrir en cada Sprint. Si no está bien, entonces intente un Sprint de una semana de duración.
Scrum fomenta el ritmo sostenible. Estamos tomando una parte de un entorno de desarrollo de proyectos/productos muy caótico y lo ponemos en una caja mágica y pacífica llamada Sprint donde el alcance podría cambiar pero el objetivo principal debe seguir siendo el mismo.
Así que la elección de la longitud del Sprint trata de pensar en lo buena que es su organización en la planificación. Esto no significa que no debas entrenar/enseñar a tu organización en una mejor planificación si están cambiando todo todo el tiempo. Sólo significa que usted debe considerar que antes de empezar a hacer algo que será inaceptable para su organización y dará lugar a rechazar Scrum antes de que incluso realmente empezar a trabajar.
En Pragmatic Coders solemos trabajar en 2 semanas de duración de la iteración, pero en algunos proyectos no utilizamos Scrum en absoluto. Kanban con WIP limitado funciona mejor en algunos casos.