¿Consejos para Sprints Cortos Especiales (2-5 Días)?

Primero, debes entender para qué sirven los sprints . Los sprints se introdujeron como uno de los métodos que ayuda a los equipos a limitar la cantidad de trabajo que se realiza en un tiempo específico. En sprint nos comprometemos a terminar un montón de tareas en algún tiempo, 2 semanas en su caso.

Sin embargo, sprint no es el único método para limitar el trabajo en curso. Otro concepto que trata el mismo tema pero de manera diferente son los límites introducidos por Kanban . En este caso, solo limita cuántas tareas pueden estar en progreso en un momento dado y no introduce cadencia para su ciclo de producción.

En ambos casos, el objetivo es evitar que grandes partes del proyecto se inicien y no se completen , aunque los conceptos sean diferentes.

Ahora, volviendo a tu pregunta: hay equipos que normalmente trabajan con sprints de una semana y están perfectamente bien. El estilo de trabajo es más o menos el mismo que con los sprints de 2 semanas. Sin embargo, significa que están trabajando en tareas bastante pequeñas, ya que pueden crear, verificar e implementar funciones en una semana . Desde esta perspectiva, un sprint de 5 días no es tan diferente: si sus tareas son lo suficientemente pequeñas, puede funcionar.

Por otro lado, el sprint de 2 días es una especie de extremo. No conozco ningún equipo que esté haciendo sprints tan cortos de forma regular. Mi pregunta sería: ¿qué es tan importante que no quieres esperar hasta el final de la semana? Nota: Considero un sprint de una semana como una alternativa aquí.

Si solo tiene que entregar en plazos tan cortos, por ejemplo, tiene SLA o se enfoca en proyectos de mantenimiento, que realmente no se ajustan a su programa de sprint regular , puede reconsiderar tener sprints . Algunos elementos de Kanban (limitación de WIP, sin bloqueo de tiempo y visualización) pueden ser un mejor enfoque en tal situación.

Algunas cosas que usted puede querer tener en cuenta:

• Cuán fluido es el equipo con el proceso actual. Cuanto mejor funcionen las cosas, menos debe apresurarse para introducir un gran cambio.
• Con qué frecuencia es necesario tener este sprint inusual. Si la anomalía ocurre de vez en cuando, debe pensar en reorganizar su proceso. Por otro lado, si sucede dos veces al año, probablemente puedas vivir con eso.
• Cuánto proceso actual se ajusta a los detalles del trabajo que realiza. Por ejemplo, los enfoques basados ​​en time-boxing no son las mejores herramientas si se trata de mucho trabajo de mantenimiento.

Responder a estas preguntas debería ayudarlo a decidir si los sprints cortos son el camino a seguir o tal vez debería reconsiderar el uso de time-boxing.

Y el último consejo final: un poco de experimentación con tu proceso siempre es algo bueno.

Te recomendaría que los conservaras si funcionan para ti. ¿Por qué arreglar algo que no está roto?

Obviamente, medir cuánto trabajo puede realizar es más fácil si todas las historias tienen un tamaño similar y todos los sprints tienen la misma duración. Sin embargo, en mi experiencia, los sprints más cortos o más largos no son malos como tales, incluso si lanzas un sprint más grande o más pequeño de vez en cuando. Solo asegúrese de tener siempre una buena razón por la que cambia algo. Recomendaría no cambiar por cambiar.

También encontrará que la planificación en particular para sprints cortos es más fácil si sus historias están en el extremo más pequeño del espectro, por ejemplo, unas pocas horas y hasta un día para completar.

Recomendaría usar Kanban durante estos períodos cortos para evitar "destruir" su configuración estándar de scrum. Si su equipo tiene un gran éxito en sus sprints regulares pero comienza a fallar en estos sprints cortos, ¡pronto también perderán la confianza en sus sprints regulares!