El Sprint es una iteración o ciclo corto de desarrollo en Scrum, cuya duración máxima es de un mes.
Los beneficios principales de hacer Sprints son:
Más allá del mes, Scrum entiende que el riesgo de que el entorno y el propio Sprint Goal cambien es excesivo. Por eso, el Sprint no puede durar más de un mes. La sucesión de Sprints y sus respectivos Sprint Goals deben acercarnos hacia la realización del Product Goal.
La duración de los Sprints ha de ser fija, para crear consistencia y evitar complejidad. No tendría sentido que, al terminar cada Sprint, tuviéramos que debatir qué duración va a tener el siguiente.
A la hora de decidir cuánto debe durar un Sprint, consideraremos factores como la necesidad de estar en contacto frecuente con stakeholders o los riesgos asociados a la tecnología.
Esta es una pregunta más bien teórica, y no hay unanimidad en la literatura al respecto ni entre formadores de Scrum.
A efectos prácticos, el Equipo Scrum suele ponerse de acuerdo en la duración del Sprint sin demasiadas dificultades (una semana, dos semanas, tres semanas o un mes).
Hipotéticamente, no obstante, el Equipo Scrum podría no alcanzar un acuerdo. En tal situación:
Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. No es necesario que el Scrum Master ni nadie de el “pistoletazo de salida”, ni que se hagan tareas de transición entre un Sprint y otro. Un Sprint concluye al terminar la Retrospectiva, y el siguiente empieza con la Planning.
Por otra parte, en Scrum no hay Sprint 0, o Sprints de puesta en producción o de resolución de errores o de testing. Estos nos llevarían a “territorio waterfall”.
Durante el Sprint se crea un Incremento de producto “Terminado”, utilizable y potencialmente desplegable.
El Sprint es un evento que actúa como continente del resto de eventos (Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva). Así, un Sprint consiste en el Sprint Planning, los Daily Scrums, el trabajo de desarrollo orientado a lograr el Sprint Goal, la Sprint Review y la Sprint Retrospective.
También durante el Sprint, realizaremos las actividades de refinamiento del Product Backlog que sean necesarias.
Durante el Sprint no se realizan cambios que puedan afectar al Objetivo del Sprint, si bien el alcance puede renegociarse entre el Product Owner y desarrolladores.
Durante el Sprint, tampoco debemos poner en compromiso la calidad del producto (por ejemplo, generando deuda técnica), sino adherirnos a la Definición de Hecho.
Un Sprint puede cancelarse antes de que llegue a su fin, si así lo decide el Product Owner, si el Sprint Goal ha quedado obsoleto. La cancelación de un Sprint es poco frecuente, en todo caso.
No hay un número predeterminado de Sprints para completar una iniciativa o proyecto. El número de Sprints, no obstante, puede estimarse. Para ello, será necesario contar un un Product Backlog cuyos elementos hayan sido estimados, y con una medida de velocidad o throughput por Sprint. El tamaño total estimado para el Product Backlog dividido entre la velocidad o throughput nos dará el número de Sprints.
No obstante, estimar con exactitud el número de Sprints que un proyecto requerirá es casi imposible en etapas tempranas, tal y como indica que el cono de la incertidumbre. A medida que la iniciativa avanza, Sprint a Sprint, el Equipo Scrum tendrá mayor conocimiento de causa y podrá realizar estimaciones más precisas.
El Design Sprint o Sprint de diseño fue popularizado por Google Ventures, que utilizó esta técnica o proceso con sus empresas invertidas. El Design Sprint es un proceso de 5 días orientado a obtener respuestas a preguntas críticas, produciendo prototipos con los que testar nuestras ideas con clientes. En este contexto, el concepto de Sprint de diseño es diferente, pero complementario al Sprint en Agile / Scrum.