El Sprint

Para asegurar un feedback continuo, un proyecto Scrum se divide en muchos " subproyectos ". A esa división es a lo que se conoce como Sprint.
Un Sprint no es más que un periodo de tiempo, en el que un Scrum Team es capaz de entregar un incremento terminado de producto. La guía de Scrum limita dicho periodo de tiempo a un" time-box "de un mes máximo, pero con un matiz importante: Cada vez que la guía especifica un " time-box "en un evento, ese tiempo se puede reducir si se finaliza el objetivo a conseguir. Sin embargo el Sprint es el único que, una vez empezado no puede cambiar su duración.
Durante un Sprint, ocurren todos los eventos de Scrum: Se comienza con el Sprint Planning, se realizan los Daily Scrum y se acaba con el Sprint Review seguido del Sprint Retrospective. Una vez acaba un Sprint, se da comienzo al siguiente.

El objetivo del Sprint es asegurarse de que el trabajo no útil (por error, porque el resultado no es lo que espera el cliente, porque las prioridades han cambiado...) es el mínimo posible. Por ese motivo, la recomendación siempre es que la longitud del Sprint sea la menor posible, de forma que la cantidad de feedback recibido sea la mayor posible, y que en caso de tener que tirar trabajo, éste se reduzca al máximo. Es decir, disminuimos el riesgo y la complejidad .
¿Cuál debe ser la longitud de un Sprint? Pues depende del equipo y del proyecto. La longitud de un Sprint debería ser la menor posible en la que el equipo se sienta cómodo para realizar un incremento de producto al final del Sprint. Si el equipo no es capaz de realizar dicho incremento, la longitud es demasiado corta y el Sprint pierde su función. Si el Sprint es demasiado largo, la cantidad de feedback se reduce y potencialmente se podría tener que deshacer más trabajo del necesario.
No obstante, a la hora de elegir una duración para el Sprint, la recomendación es hacerla en semanas. ¿Significa esto que está prohibido hacer Sprints de 3 días? No. La duración del Sprint es libre, siempre que sea menor a un mes. Sin embargo, por logística para el equipo y sobre todo para los Stakeholders, es mejor hacerlo en semanas. Con ello conseguirás que todos tengan en su calendario algo como "cada dos lunes tengo una reunión con el equipo XXX para su Sprint Review". Si en lugar de eso tienes que una semana la reunión es el jueves, la siguiente es martes, la otra no hay... sólo conseguirás que el número de Stakeholders que asistan se reduzcan por problemas de agenda.

Otra recomendación es, que según avanza el proyecto y con el acuerdo del equipo e interesados, se juegue con la duración del Sprint.
Sé lo que estás pensando: " ¡Pero si los Sprints tienen todos la misma duración! ". Es cierto, los Sprints son de duración fija y no se cambian... una vez empezados . No vale incrementar el Sprint un par de días para que dé tiempo a terminar la última tarea. Si una tarea no se ha terminado, se verá en las reuniones dedicadas a la inspección (Review y Retrospective) qué ha pasado con ella, por qué no se ha terminado y qué acciones se pueden tomar a futuro para evitar que pase de nuevo. Si se amplía un Sprint una vez empezado, sólo consigues engañarte a ti mismo.
Explico la idea con un ejemplo: Llevamos 5-6 Sprints con una cadencia de 3 semanas y vemos que estamos entregando más trabajo de lo que podríamos considerar como "mínimo producto viable". Ahí podríamos ver con el equipo e interesados la opción de bajar la cadencia a 2 semanas, probar durante 2-3 Sprints y ver qué pasa. Para estos casos, tenemos siempre en cuenta los pilares de Scrum (transparencia, inspección y adaptación), así que básicamente probamos, si va bien lo mantenemos y si no funciona volvemos a como estábamos.

Durante un Sprint:

• No se realizan cambios que puedan afectar al Sprint Goal (objetivo del Sprint).
• Los objetivos de calidad no disminuyen
• El alcance puede clarificarse y renegociarse entre el Product Owner y el Development Team según se aprende.

" Creo que lo entiendo. Mi objetivo del Sprint es hacer un formulario de color verde para una web y mi Sprint de un mes empezó hace 3 días. Me acabo de enterar que el cliente quiere cambiar los verdes por naranjas, pero como la duración del Sprint no se cambia una vez empezado y tampoco se admiten cambios que afecten al objetivo, pues dentro de 27 días, en el Sprint Review me dirán que en lugar de verde lo quieren naranja y ya "

Si se te ha pasado lo anterior por la cabeza, sigue leyendo: Scrum no va en contra del Agile Manifesto. Dos de los puntos del Agile Manifesto son "Respuesta ante el cambio" y "Colaboración con el cliente", y parece claro que la idea anterior no va por el mismo camino. El cliente no estará muy contento si le decimos que el plan era poner verde y hasta dentro de un mes no vamos a cambiar el plan.
Si sabemos que el objetivo del Sprint se ha vuelto obsoleto, Scrum permite realizar lo que se conoce como "Cancelación del Sprint".
La cancelación del Sprint la realiza el Product Owner (aunque pueden solicitárselo los Stakeholders, el Scrum Master o el Development Team) cuando el el objetivo del Sprint queda obsoleto. Esto puede pasar por un cambio de dirección de la compañía, de las condiciones del marcado o de la tecnología, entre otros. En general, cuando el Sprint deje de tener sentido dadas las circunstancias.
Cuando se cancela un Sprint, se realiza un Sprint Review para ver si los elementos terminados pueden ser entregables. Todos los no terminados pasarán al Product Backlog, donde el Product Owner los revisará. Si tienen sentido, se reestimarán y si no, desaparecerán del Product Backlog.
Dado que las cancelaciones de Sprint consumen recursos, suelen ser traumáticas para el Scrum Team y los Sprints son de corta duración, es algo muy infrecuente y rara vez tienen sentido. No obstante, y como otro punto más a favor de los Sprints cortos, mientras menor duración tenga éste, más improbable es que se produzca una cancelación.
Por último, una duda muy común que me hacen con la duración del siguiente Sprint tras una cancelación: ¿Duración normal o se disminuye el nuevo para que finalice cuando se esperaba que finalizara el cancelado? Pues como todo, depende. Lo ideal es que el nuevo Sprint tenga la cadencia normal que estaban teniendo los Sprintsanteriores, sin embargo, por motivos logísticos lo más habitual es que el nuevo Sprint sea de una duración menor a la habitual para que el Sprint Review del nuevo coincida con el ya estaba planeado para el que se canceló, siempre que el equipo sea capaz de terminar algo entregable para esa fecha. Cualquiera de las opciones es igualmente válida.