Qué duración debe de tener un Sprint y por qué no variar la duración de los mismos

“Si todos están avanzando hacia adelante juntos, entonces el éxito llegará por sí mismo”

Henry Ford

Hoy quiero hablar de este tema, porque en numerosas ocasiones me he encontrado con estas pregunta:

  • “Me queda poco para terminar ¿puedo alargar dos días el sprint?”
  • En verano que no está la mitad de la gente, ¿Podemos ajustar la duración del Sprint?

Y del tipo de estas alguna más. La guía Scrum deja muy claro este tipo de respuesta, y cito textualmente:

“El corazón de Scrum es el Sprint…”

Sprints tienen duración consistente a lo largo de todo el esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior…

Si me ha ocurrido en alguna ocasión, cuando se ha creado un equipo nuevo, que el equipo no se adapta realmente a la duración establecido primero, y se acuerda un cambio de duración de los Sprint, y por supuesto es lícito, pero eso no significa que podamos ir variando los Sprint a nuestro conveniente.

A parte de la guía de Scrum, otros motivos para no variar la duración

Es cierto que scrum establece que la duración de los sprints debería ser consistente, pero ello no implica que no puedan realizarse cambios. Es decir, como regla general los equipos no deberían cambiar la duración del sprint a no ser que fuera por “razones de peso”.

¿Qué puede entenderse por razones de peso? Razones de peso no son que el Equipo necesite un par de días extra o unas horas, para concluir el trabajo que tiene empezado.  Razones de peso podrían ser, por ejemplo: reducir el tamaño del Sprint para obtener un feedback con mayor frecuencia, o hacerlo por razones prácticas en base a motivos fiscales.

Ni siquiera debería modificarse el tamaño del sprint, cuándo durante el siguiente sprint, haya  prevista una formación de varios días, o vayan a tener lugar uno o dos días festivos. Ambos casos, se deben tener en la planificación del Sprint y tenerlos en cuenta para prever la capacidad del equipo. Pero estas razones, no justifica cambiar el tamaño del sprint.

Mantener los sprints constantes favorece la cadencia. Esta hace referencia al ritmo regular o predecible del esfuerzo del equipo de desarrollo para concluir historias de usuario. Es decir, ciertas actividades y el ritmo de trabajo se torna habitual, lo que permite que el equipo se centre en otros aspectos más importantes (generar valor).

Por otro lado, la duración constante de los sprints simplifica la planificación. Al mantener constante el tamaño de los sprints se normaliza la velocidad del equipo, permitiendo una mejor planificación. Además, el equipo está acomodado al ritmo de trabajo y es capaz de estimar mejor su capacidad de trabajo.

Consecuencias de no respetar los tiempos

No respetar los tiempos de los Sprint suele llevar dos consecuencias muy negativas:

  • Se pierde la cadencia. Los sprints llevan un ritmo planificado desde el principio del proyecto. Si no respetamos la duración de cada sprint, este ritmo se pierde, y por lo tanto estaremos aislando cada parte del trabajo, en lugar de ver el proyecto como un trabajo común.
  • Los equipos no se ajustan a los tiempos dados. Si cambiamos constantemente la duración de los sprints, el ritmo de cada equipo será menor, ya que no será necesario que completen los puntos de historia a tiempo. Trabajarán con la posibilidad de aumentar el sprint siempre que sea necesario y no se crea esa responsabilidad de entrega.
  • Además, no podrá haber una planificación real, la velocidad del equipo irá variando, y no se podrá prever bien la cantidad de trabajo a realizar en el Sprint. Y esto es importante, porque el equipo dejará de tomar conciencia de métricas y de usarlas para mejorar.

¿Cómo determinar la mejor duración del Sprint?

Uno de los resultados de la planificación de Sprint es una fecha de Demo de Sprint definida. Eso significa que debes determinar una duración del Sprint.

La duración del sprint afecta de forma importante en la manera de trabajar del equipo. ¿Cuál es la mejor duración de sprint? Como siempre no es una respuesta de blanco o negro, cada duración tiene sus ventajas e inconvenientes.

Sprint cortos (1/2 semanas)

  1. Los Sprints cortos están bien. Permiten a la compañía ser “ágil”, es decir, cambiar de dirección frecuentemente.
  2. Mejora la comunicación con negocio al acortar los ciclos de comunicación y permite obtener más feedback 
  3.  Entregas más frecuentes eso da lugar a más feedback del cliente y menos tiempo desarrollando en dirección incorrecta.
  4. Mejora el aprendizaje del equipo sobre su forma de trabajar y su cohesión como equipo. 
  5. Al estar más cerca el fin del Sprint, hay más presión sobre el equipo, lo que evita el principio de Parkinson, el síndrome del estudiante o el parálisis por análisis, pero de esto ya hablaré en otros post.  
  6. Reacciona mucho más rápido a los cambios de dirección o estrategia.
  7. Corrige antes una dirección equivocada. Un fallo técnico o entender mal lo que quería negocio son ejemplos de dirección equivocada.
  8. Permite hacer releases más rápido (si tu tecnología lo permite). Esto reduce la deuda por ramas abiertas.
  9. Evita silos de conocimiento. Los sprints largos pueden acomodar mejor los silos dentro del equipo al poder acomodar tareas de cada dominio de conocimiento. Los cortos exigen en muchas ocasiones la colaboración y enfocarse todos en lo mismo ya que no da tiempo a tratar varias cosas a la vez.

Sprint largos (3/4 semanas)

Los Sprints largos tampoco están mal. 

  1. Se convierte en más sencillo “acomodar” historias dentro del Sprint que conformen un objetivo con valor real y que pueda notar negocio.
  2. El efecto de incidencias, consultas y otras interrupciones habituales se difumina más en los sprints. Un sprint corto puede quedar “destrozado” por un par de incidencias gordas. Uno grande resiste mucho más.
  3. Se adapta mejor a proyectos en los que la Release es costosa y posiblemente fijada en el tiempo. Por ello suele ser mejor en proyectos legacy.
  4. Es más robusto a vacaciones, enfermedades del equipo o días festivos.
  5. La velocidad del equipo, por estadística, es más constante y predecible, al reducirse también la precisión de las estimaciones.
  6. El impacto de reuniones o eventos relacionados con Sprints (planning, review, demo, retro, …) es menor ya que se realizan menos veces.

Generalmente, los POs prefieren los Sprints cortos y al equipo técnico les gustan los Sprints largos. Así que la duración del Sprint es un valor de compromiso. 

En mi experiencia, al inicio del equipo, del proyecto, se ha experimentado con varias duraciones, en mi trabajo anterior, estaban cómodos con dos semanas de Sprint, en mi trabajo actual, todos los equipos con los que trabajo tiene 3 semanas de duración.

A una conclusión a la que he llegado es, que se necesita experimentar al principio con la duración del equipo, y no perder tiempo en pensar por donde empezamos, sino empezar, analizar y reflexionar y si ese periodo de tiempo no es adecuado para el equipo cambiar.

En cualquier caso, una vez que se haya establecido una duración, es buena práctica mantenerla durante un buen periodo de tiempo. Después de unos pocos meses de experimentar, se encuentra el tiempo adecuado.

Terminando…

Después de enumerar pros y contras, y de ver qué pone en la guía de Scrum, podríamos decir que hay varios aspectos clave que pueden apoyar un Sprint corto o largo.

  • ¿Hacer una release es como un parto y sólo la puedes hacer una vez al mes? Sprint largo
  • ¿Hay muchos problemas con la aplicación y todas las incidencias son urgentes y no pueden esperar? Sprint largo
  • ¿Cuando hay incidencias, no suelen ser de vida o muerte y no pasa nada si esperamos una semana? Sprint corto
  • ¿Sois adictos a la reunionitis en la cultura de tu empresa? Sprint largo
  • ¿El producto no está bien definido y se espera hacer muchos cambios sobre el plan? ¿Es un producto para una nueva línea de negocio Sprint corto
  • ¿Tecnología o arquitectura nueva que desconocemos al empezar? Sprint corto

Y la respuesta comodín:

¿Sigues sin tener ni idea de qué duración escoger? Pues escoge 2 semanas.

¡Feliz miércoles! Y recordar, respetar los tiempos de Sprint!

2 comentarios sobre “Qué duración debe de tener un Sprint y por qué no variar la duración de los mismos

  1. Hola María, buen artículo, interesante como todo lo que escribes. 🙂
    Creo que hay una pequeña errata en la frase:
    «En mi experiencia, al inicio del equipo, del proyecto, se ha experimentado con varias duraciones, en mi trabajo anterior, estaban cómodos con dos Sprint, en mi trabajo actual, todos los equipos con los que trabajo tiene 3 semanas de duración.»
    Supongo querías decir: «… estaban cómodos con dos semanas, …»
    En vez de: «… estaban cómodos con dos Sprint, …»
    Un afectuoso saludo.

  2. Hola Rafa!!! Qué alegría ver tu comentario, muchas gracias por leerlo y por el feedback!!!

    Tienes toda la razón del mundo, no me dí cuenta al escribirlo antes de irme de vacaciones! Lo corrijo ya mismo,
    Muchísimas gracias!
    Un abrazo enorme!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.