“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. El sprint corto es bueno. Hacen que la empresa sea «ágil», es decir, cambian de dirección con frecuencia.
2. Mejora la comunicación con la empresa acortando el ciclo de comunicación y proporcionando más comentarios.
3. Las entregas más frecuentes darán lugar a más comentarios de los clientes y reducirán el tiempo de desarrollo erróneo.
4. Mejora la comprensión del equipo de sus métodos de trabajo y la cohesión del equipo.
5. A medida que se acerca el final del Sprint, la presión sobre el equipo aumenta, lo que evita el inicio de la enfermedad de Parkinson, el síndrome del estudiante o la parálisis por análisis, pero hablaré de esto en otras publicaciones.
6. Reacciona más rápido a los cambios de dirección o estrategia.
7. Primero corrige la dirección incorrecta. Una falla o un malentendido del negocio que desea es un ejemplo de la dirección equivocada.
8. Permite una liberación más rápida (si su tecnología lo permite). Esto reduce la deuda de las ramas abiertas.
9. Evita las islas del conocimiento. Los sprints a largo plazo pueden adaptarse a las tareas de cada área de conocimiento y pueden adaptarse mejor a las islas del equipo. Los sprints cortos generalmente requieren cooperación, y concentración, porque no hay tiempo para lidiar con varias cosas al mismo tiempo.

Sprint largos (3/4 semanas)

Los Sprints largos tampoco están mal. 

1. Es más fácil «acomodar» las historias en el Sprint, que constituyen metas con valor práctico y la empresa puede darse cuenta.
2. El impacto de los eventos, las consultas y otras interrupciones comunes se oscurece aún más en el sprint. Varios eventos importantes pueden «destruir» los sprints cortos. Un sprint grande resiste más.
3. Es más adecuado para proyectos en los que la versión de lanzamiento es cara y se puede arreglar en el tiempo. Por lo tanto, suele ser mejor en proyectos heredados.
4. Para vacaciones, enfermedades del equipo o vacaciones, es más potente.
5. Hablando estadísticamente, la velocidad del dispositivo es más estable y predecible porque la precisión de la estimación también disminuirá.
6. Las reuniones o eventos relacionados con Sprint (planificación, revisión, presentación, revisión, …) tienen menos impacto porque se llevan a cabo con menos frecuencia.

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!