Consejos para escoger la duración del Sprint

2

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. Así que me he dispuesto a intentar enumerar todas las que se me ocurren.

Consejos generales

  1. La duración estándar de Sprint, con la que la mayoría de equipos trabajan, es de 2 semanas.
  2. Los límites habituales para la duración están entre 1 y 4 semanas. Hay casos con Sprints más cortos o más largos, pero se salen de lo habitual.
  3. Es posible ir “amoldando” la duración del Sprint a las tareas a realizar, pero esto no lo recomiendo al ir rompiendo las dinámicas semanales. Mejor amolda las tareas a realizar a la duración.
  4. La duración del sprint es algo que se puede cambiar. Si tras varios sprints (alrededor de 5 por ejemplo) el equipo no está cómodo con la duración, se puede cambiar y probar otra duración.
  5. Aunque suele ir ligada, las releases no tienen porque ir sincronizadas con los Sprints. Se puede hacer release varias veces dentro de un sprint.

Habiendo planteado esto, los sprints cortos tienen sus ventajas y los largos las suyas. Por supuesto lo que es una ventaja para el corto, se convierte en un inconveniente en el largo.

Ventajas de un Sprint Corto

Hablamos de sprints de 1 o 2 semanas. Con una semana estas ventajas se acentúan.

  1. Mejora la comunicación con negocio al acortar los ciclos de comunicación.
  2. Mejora el aprendizaje del equipo sobre su forma de trabajar y su cohesión como equipo. Este tema lo traté en “Sobre la evolución de las especies y la duración de los Sprints”.
  3. 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 Análisis-Parálisis.
  4. Reacciona mucho más rápido a los cambios de dirección o estrategia.
  5. Se reduce la cantidad de incidencias urgentes que deben ser tratadas en el Sprint. Un sprint muy corto puede contestar “al siguiente Sprint” para la mayoría de incidencias. Uno largo, no se lo puede permitir.
  6. Corrige antes una dirección equivocada. Un fallo técnico o entender mal lo que quería negocio son ejemplos de dirección equivocada.
  7. Permite hacer releases más rápido (si tu tecnología lo permite). Esto reduce la deuda por ramas abiertas.
  8. 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.

Ventajas de un Sprint Largo

Hablamos de sprints de 3 o 4 semanas y en algún caso incluso superiores (aunque hay quien diría que entonces ya no son Sprints.

  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.

Conclusiones

Después de enumerar pros y contras, 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 que duración escoger? Pues escoge 2 semanas.

SCRUMSprint

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

2 comments

  1. Julio 12 marzo, 2019 at 13:45 Responder

    Creo que nunca había leido lo de los silos y desde luego no lo había pensado, pero le veo mucho sentido.
    Ojo porque un sprint largo tiene el riesgo de convertirse en un minicascada ya que precisa de mucho más coste de planificación y preparación al haber más historias.

    • Jose M. Huerta 12 marzo, 2019 at 22:27 Responder

      Cierto que es más difícil tender a cascada con sprint cortos, pero no subestimes el poder de la fuerza. Cuando los tickets de “Analizar tal cosa” comienzan a aparecer como si fuesen historias de usuario, ni los sprints cortos pueden pararlo…

Post a new comment