Indice de contenidos
¿Qué sucede durante el Sprint?
El Sprint o iteración empieza con una Planning, donde planificamos el trabajo que vamos a realizar para alcanzar nuestro Sprint goal, que nos ayudaría a avanzar hacia nuestro Product Goal.
Después del Planning, el equipo realiza un evento diariamente que se llama Daily Scrum para inspeccionar y adaptar el plan para alcanzar el Sprint Goal, que se supone que el Scrum Team creó durante el evento del Sprint Planning.
Al final del Sprint el equipo Scrum realiza un evento de negocio que se llama Sprint Review, para inspeccionar el incremento (resultado del Sprint) con los stakeholders y adaptan en modo colaborativo el Product Backlog, revisan el roadmap, la situación del mercado, etc.
Y como último evento el equipo en su conjunto se junta para inspeccionar, herramientas, relaciones, procesos, tecnologías, etc. y buscan cómo pueden mejorar, como resultado el equipo creará un plan de acción de mejora que llevará al siguiente Sprint.
Una vez terminada la iteración, que se cierra con la Retrospectiva, empieza el siguiente inmediatamente.
Otros elementos a tener en cuenta durante el Sprint
Cuando se está utilizando Scrum como marco de trabajo, es importante tener en cuenta lo siguiente durante la iteración:
- Es importante no realizar cambios que pongan en riesgo la consecución del Sprint Goal
- Como acto, refinamos el Product Backlog para ordenarlo y tener más arriba del mismo elementos Ready to Start ( para ello es importante tener un Definition of Ready ) para el siguiente Sprint
- Una vez arrancada la iteración, el equipo irá aprendiendo sobre el trabajo, y podrá encontrar problemas, soluciones, incluso complicación para alcanzar el Sprint Goal, y ahí deberá de renegociar el alcance del Sprint goal con el Product Owner
- Cuando el equipo no puede llegar a alcanzar todo el scope, en ese caso, hacemos lo que acabamos de comentar, el Sprint Goal se negocia su alcance entre el Po y los desarrolladores, pero, NUNCA LA CALIDAD.
¿Qué hay entre Sprints?
Lamentablemente, no hay espacios muertos entre Sprints 🤷 🤷 🤷, no hay Sprint para estabilizar una release, despliegues, hacer pruebas, ni para ajustar ciertos retoques. Si esto sucede es un síntoma claro de una disfunción dentro del Scrum Team y hay que buscar mejoras para ello. Hay que recordar que un Sprint comienza inmediatamente después del anterior.
¿Quién puede cancelar un Sprint?
En mi experiencia en muchos años de trabajo con equipos Scrum, solo me pasó 2 veces que un Sprint haya tenido que ser cancelado. Y cuando esto pasó el Product Owner canceló el Sprint, en otras palabras, solo el PO puede cancelar el Sprint.
Muchas veces esto puede pasar cuando el objetivo del Sprint queda obsoleto, aunque a veces no merece la pena cancelarlo, sobre todo si el equipo hace Sprints de una semana de duración. Por otro lado, se puede plantear el debate sobre cancelar un Sprint cuando la organización cambia de rumbo a nivel estratégico, esto también nos puede llevar a cancelar el Sprint
¿Quién puede decidir la duración del Sprint?
Es un tema bastante confuso, mucha gente piensa que es el Scrum Master quien debe decidir la duración de un Sprint, WHAT 😲 😲 😲? Desde mi punto de vista, hay 3 elementos claves a la hora de decidir la duración del Sprint:
- Que el equipo sea capaz de crear un incremento de valor en ese espacio (siempre menos de un 1 mes)
- Que el Product Owner lo considere según las necesidades del mercado, usuarios, etc. El PO puede necesitar una duración X para chequear el mercado , recoger feedback y adaptar el Producto
- Los stakeholders pueden tener mucho que decir sobre este punto, ya que con ellos vamos a inspeccionar el producto y adaptar el Product Backlog, además son una fuente de feedback importante para ajustar el producto. Sin olvidar el punto de antes.
Cuando se está debatiendo sobre la duración del sprint, hay que pensar que los Sprints nos brindan en cierta medida predictibilidad a través la inspección y adaptación del progreso hacia nuestro Product Goal. Por lo tanto, si el Sprint tiene una duración muy grande, la complejidad aumenta y los riesgos se disparan. Hay que recordar que los entornos de desarrollo de software son complejos y desconocemos más que conocemos sobre los Qué’s o los Cómo’s, de hecho si los niveles de incertidumbre son muy altos, es mejor utilizar Sprints muy cortos para poder aprender y mejorar más rápido y reducir los riesgos de pérdidas o costes. Aquí podemos considerar que cada Sprint es un proyecto.
Te dejo un enlace de ScrumOrg sobre ello y otro enlace de wikipedia sobre ello
si te ha gustado, ayúdame compartiendo y valorandolo.
