Si los procesos de trabajo se organizan según el principio de Scrum, hay ciertos acontecimientos que ocurren con frecuencia. Dado que Scrum es un proceso iterativo, el trabajo se realiza en ciclos que se repiten: cada evento se reinicia con cada repetición y la frecuencia de los eventos Scrum hace que las reuniones no programadas rara vez (o incluso nunca) tengan lugar, de ahí que todos los eventos tengan un plazo establecido.
El ciclo recibe el nombre de sprint, concepto que describe el espacio de tiempo de una fase de desarrollo. Al final de un sprint, el equipo de desarrollo entrega un incremento de producto ya terminado, lo que significa que el desarrollo debe haber conducido a un producto que tenga potencial. Por lo tanto, cada sprint tiene una misión concreta que al final se marca como “hecho”.
El plazo de tiempo para un sprint debe establecerse de antemano y no debe superar los 30 días. Para determinarlo deben tenerse en cuenta los siguientes factores: un sprint no puede ni acortarse ni alargarse y los siguientes sprints del proyecto deben tener la misma duración.
Los sprints son cortos para que, a la hora de formular los objetivos, se mantenga la simplicidad. Esta corta duración determina la realización de un análisis del desarrollo al menos una vez al mes. En casos excepcionales, el product owner es el único que puede interrumpir el sprint. La cancelación es posible, por ejemplo, cuando ya no tiene que alcanzarse el objetivo porque la empresa tiene otros propósitos. Fundamentalmente, los sprints no deben interrumpirse, pues esto disminuye la productividad
Un sprint comienza con el sprint planning (planificación de los sprints), donde participan todos los roles del equipo Scrum. Durante una reunión de hasta un máximo de ocho horas, las partes implicadas hablan del próximo incremento de producto: ¿qué debe incluir el incremento y cómo quiere lograrse? El punto de partida para la planificación es el product backlog (lista de producto). El equipo de desarrollo y el product owner acuerdan conjuntamente cuáles son los objetivos que deben lograrse el próximo mes y, a continuación, el equipo de desarrollo habla sobre cómo deben llevarse a cabo las tareas. Al final de la reunión, los desarrolladores deben dialogar sobre su plan con el product owner y el Scrum master.
En el sprint tiene lugar un daily Scrum (Scrum diario) todos los días, siempre a la misma hora y en el mismo lugar, lo que ahorra esfuerzos organizativos. En cada reunión, de 15 minutos, el equipo de desarrollo conversa sobre las tareas pendientes del día y lo que se ha logrado el día anterior. Asimismo, los desarrolladores evalúan el progreso general del proyecto: ¿cuál ha sido el progreso con respecto al procesamiento de las entradas del backlog? La comparación diaria garantiza que las personas implicadas no pierdan de vista los objetivos, lo que también aumenta la productividad.
Aunque el Scrum master se encarga de que tenga lugar el daily Scrum, pero son los desarrolladores los encargados de determinar el curso de la reunión y quienes establecen los temas que se van a tratar. Mientras que en términos de contenido se trate de conseguir el objetivo del sprint y no se superen los 15 minutos, el Scrum master no se inmiscuye, sino que se centrará en que otras personas presentes en el daily Scrum no entorpezcan el trabajo de los desarrolladores.
Cuando termina un sprint, el paso siguiente es el sprint review (revisión del sprint), en el que se examina el incremento de producto. Los resultados se analizan junto a aquellos que no forman parte del equipo Scrum pero que tienen un gran interés por el producto, como, por ejemplo, la gerencia de la empresa o los clientes (denominados stakeholders en el ámbito Scrum). En este contexto, también se habla del proceso de trabajo, se tratan los problemas en el desarrollo y se intercambian ideas sobre los diferentes retos, lo que también influye en la planificación posterior, puesto que el product owner se vale de la oportunidad de responder al avance del backlog. Los conocimientos del sprint influyen en la previsión del rendimiento futuro.
Lasituación del mercado en el momento también influye en el backlog:en el caso de los proyectos de larga duración sobre todo, las prioridades pueden cambiar y los presupuestos modificarse. Estos temas también se tratan en la revisión del sprint, ya que modifican el planteamiento futuro. En un sprint de un mes no deben emplearse más de cuatro horas para la revisión, la cual va seguida de otra revisión: la retrospección del sprint.
En una reunión de un máximo de tres horas, el equipo Scrum al completo (incluidos el product owner y el Scrum master, pero no los stakeholders) lleva a cabo una sesión de feedback. Mientras que en la revisión el elemento central es el producto y el avance del proyecto, en la retrospección prevalece el trabajo en equipo. El objetivo de esta segunda revisión es mejorar el trabajo entre las partes y sortear los problemas internos. Cuando acaba un sprint, el siguiente empieza con el sprint planning.