También es el "timebox" principal que regula todos los demás.
La idea de TimeBox se utiliza en Scrum para el Sprint y todos sus eventos internos, y es lo que me gusta llamar una "restricción creativa". A primera vista parece una limitación, pero nos ayuda a mantener uno de los valores, que es el FOCO. Una vez que decidimos cuánto va a durar el Sprint de nuestro equipo, no podemos cambiarlo, y eso nos obliga a tener que aprender a entregar y organizarnos dentro de ese límite.
Según la Guía de Scrum, el Sprint puede durar un máximo de un mes, aunque en la práctica ya son muy pocos los equipos que mantienen Sprint de un mes, que suena a una eternidad. La duración más popular es la de dos semanas, pero es usual que los equipo más maduros prefieran el Sprint semanal.
La condición inicial para poder iniciar un Sprint es tener el Product Backlog listo para planificar el trabajo de todo el Sprint. Esto implica que al menos los Items del Product Backlog (o PBIs) más prioritarios estén lo suficientemente refinados.
La duración del Sprint es la que afecta a la vez el timebox máximo de cada uno de sus eventos interiores. Pero lo más importante es recordar siempre que todo sucede dentro del Sprint. Desde el punto de vista de Scrum, nada sucede fuera del Sprint.
Preguntas frecuentes acerca de los Sprints
¿Nunca se puede cambiar la duración del Sprint?
Sí, es posible hacerlo, pero con mucho cuidado.
El motivo no debería ser circunstancial. Lo que no vale es cambiar arbitrariamente, agregando o quitando días por cualquier circunstancia, ni decidiendo en cada Sprint cuánto va a durar.
Personalmente encuentro solamente dos motivos para cambiar (en algún momento de la vida de un producto):
- Que el equipo intentó con una duración muy corta y no le resulta sostenible. Por ejemplo, intentaron Sprints de una semana y descubrieron que algunos temas técnicos o internos hacen que les resulte demasiado difícil entregar un producto funcionando al final de cada semana. En ese caso, luego de analizarlo en una Retrospectiva, podrían decidir decidir cambiar a Sprints de dos semanas (de ahí en adelante, sin seguir variando todo el tiempo).
- De forma similar, si el equipo comenzó con Sprints de dos o tres semanas y durante una Retrospectiva deciden que ya están lo suficientemente maduros como para hacer Sprints más cortos y así aumentar la frecuencia del feedback, podrían reducirlo (nuevamente, es importante que estén seguros de que será sostenible, para no tener que volver atrás).
En cualquiera de los dos casos, es importante que antes de cambiar la duración, tanto el motivo como la decisión sea comunicada a los stakeholders principales, más allá del Equipo Scrum, porque para quienes asistan a la mayoría de las Sprint Review, ese cambio de frecuencia es importante.
¿Se puede cancelar un Sprint antes de que termine?
Sí, es posible hacerlo, pero con mucho cuidado.
(No, no es déjà vu, la respuesta es la misma que la anterior. 😄)
Después de más de 10 años trabajando con Scrum, recuerdo presenciar un solo caso de cancelación, y era porque la compañía acababa de ser adquirida por otra, y no se sabía si el producto continuaría existiendo.
Los únicos motivos para cancelar un Sprint es que su Objetivo se vuelva totalmente obsoleto, por un cambio de negocio, mercado o tecnología tan enorme que cambia todo el contexto. Esto sucede muy raramente. Aunque la idea puede venir de cualquiera, la responsabilidad de cancelarlo (comunicándolo a todos los demás) es únicamente del Product Owner.
