Eventos Scrum: Sprint
Seguimos revisando los eventos de Scrum. En esta ocasión el turno es para mirar el evento llamado Sprint.
En palabras de Ken Schwaber y Jeff Sutherland para la guía definitiva de Scrum, el corazón del framework es el Sprint. Para entender de mejor forma su propósito, es necesario mencionar un aspecto al que se le llama time-box.
Todos los eventos de Scrum se rigen por bloques de tiempo. Para el caso del Sprint, es explicita la regla: el máximo tiempo de duración debe ser de un mes pero no dice cuanto es el mínimo. Así, un Sprint puede durar entre una y cuatro semanas. Por ejemplo, me ha tocado trabajar en el desarrollo de productos donde ejecutamos Sprints de una semana, lo que ofrece ciertas ventajas como lo son: mejorar la comunicación del equipo ya que las retrospectivas son semanales y esto se traduce en action items que facilitan la adaptación del proceso y las relaciones de los individuos en sus interacciones y facilita a equipos novatos el reducir la incertidumbre y controlar mejor la predictibilidad al tener un período extremadamente corto de ejecución. Sin embargo, le juega en contra que al distribuir los cinco eventos de Scrum en una semana, disminuye el tiempo disponible para el desarrollo y la ejecución de las reuniones definidas por el marco de trabajo no ayuda mucho a mejorarlo. Sobre todo si los Sprints tan cortos no son soportados por una buena infraestructura tecnológica que permita la entrega continua al ritmo pretendido y una velocidad sostenible. Por otra parte, aumentan las posibilidades de cansancio y desgaste en los equipos, lo que podría llegar a influir en la motivación y el compromiso. Se ha hablado en reiteradas ocasiones acerca de no confundir el valor entregado con el tener a las personas literalmente reventadas trabajando. El tomar tareas y no terminarlas por que el proceso no está lo suficientemente automatizado y además no se cuenta con el tiempo suficiente para adaptarlo, lógicamente aumenta el riesgo para los Sprints siguientes.
Los Sprints de dos semanas permiten equilibrar el alcance versus tiempo de una forma en la cual no hay una rapidez extrema y agobiante pero tampoco un periodo tan extenso de espera para mejorar la entrega (como el caso de los Sprints de tres y cuatro semanas) y le brinda al Product Owner tiempo suficiente para asegurarse de contar con un Product Backlog refinado con las mejores prácticas. Cuando se utilizan más de dos semanas, suelen ocurrir problemas con el alcance y las definiciones del negocio podrían haber cambiado todavía sin estar validando ni entregando al usuario final: nada.
De todas maneras, es importante recalcar que el time-box del Sprint lo deciden los equipos y el periodo de tiempo que duran en un proyecto, no tiene por que ser el mismo para todos los demás proyectos. Mucho menos en distintas organizaciones. Todo depende del contexto. Además, no debemos olvidar que en el ámbito de la complejidad, el todo es mas que la suma de las partes. Dicho esto, replicar lo que te resultó en una adopción, tendrá un resultado distinto en otro sistema.
El Sprint es el contenedor de los cuatro eventos restantes. Así, cuenta con: el Sprint Planning, las Daily Scrum, el desarrollo del incremento del producto, una Sprint Review y una Sprint Retrospective.
El único rol que tiene la facultad de poder cancelar un Sprint es el Product Owner. No es usual que esto suceda, pero puede darse dicho escenario por diversos factores. Las historias de usuario ya no representan al negocio, cambiaron las condiciones del mismo, la planificación del Sprint no fue capaz de visualizar los bloqueos por dependencias que salieron a la luz al momento de la ejecución (principalmente por refinamientos pobres y malas planificaciones de Sprints), etc.
Para terminar, contando con una buena suite de integración continua no llega a ser estrictamente necesario esperar hasta el final del Sprint para desplegar los entregables por historias. Teniendo esa implementación, los pilares de inspección y adaptación cobran mucha, pero mucha mas fuerza en la Daily Scrum.
Saludos!