Hace algún tiempo me preguntaron por la duración de los sprints en los equipos en los que trabajaba, y les contesté que eran habitualmente de dos semanas. Habíamos hecho alguno de solo una semana, pero nos parecía demasiado overhead de reuniones y eventos de Scrum. También alargábamos a tres semanas durante las vacaciones de verano y Navidad, pero teníamos la sensación de perder de vista en qué semana del desarrollo estábamos.

Ya no veo tan mal los sprints de una semana. Con los de dos vemos siempre que la gráfica de burndown se mantiene plana durante todo el sprint, y baja solo durante los dos últimos días de la iteración (ya conocemos la Ley Parkinson: el trabajo se expande hasta que ocupa por completo el tiempo destinado para su realización).

Con solo una semana por sprint, la gráfica sufre el mismo problema, pero en la mitad de tiempo. Además es más fácil acertar en la velocidad del equipo y lo que puede comprometerse: tienes una mejor idea de lo que puedes hacer en solo cinco días (y reaccionar si surge algo imprevisto). Cuestión de seguir probando.