Scrum está pensado como un marco simple pero suficiente para la entrega de productos complejos. Scrum no es una solución única, una bala de plata o una metodología completa. En cambio, Scrum proporciona los límites mínimos dentro de los cuales los equipos pueden autoorganizarse para resolver un problema complejo utilizando un enfoque empírico. Esta simplicidad es su mayor fortaleza, pero también es la fuente de muchas malas interpretaciones y mitos que rodean a Scrum. En esta serie de publicaciones, nosotros, sus ” Cazadores de mitos “, Christiaan Verwijs & Barry Overeem, abordaremos los mitos y malentendidos más comunes. 

PD: Las grandes imágenes son de Thea Schukken.

¿Los equipos de desarrollo se comprometen — esencialmente prometen —  a completar todos los items del Product Backlog en cada Sprint? ¿Pueden las nuevas ideas surgidas durante el Sprint resultar en cambios en el Sprint Backlog? ¿O se fijó el Sprint Backlog? En esta publicación abordamos el mito de que el Sprint Backlog se fija durante el Sprint.

¿Qué dice la guía Scrum?

El Sprint Backlog representa el trabajo que un equipo de desarrollo necesita sacar del Product Backlog para lograr el Sprint Goal. El Sprint Goal es una meta establecida por el Equipo Scrum durante el Sprint Planning y captura la hipótesis de que el equipo quiere probar una meta que quiere lograr o un experimento para ejecutar. Aunque el Sprint Goal se fija durante el Sprint en el Sprint Backlog no aplica lo mismo. Esto nos devuelve a una premisa central de Scrum: el trabajo complejo es altamente impredecible y no se puede planificar en detalle. Incluso si ese futuro es un Sprint único, la comprensión del trabajo que debe hacerse se perfeccionará y cambiará a medida que avancen los días.

Por ejemplo, un equipo de desarrollo podría aprender que una tecnología que eligieron no funciona como se esperaba. O una característica clave necesaria para alcanzar el Sprint Goal se perdió durante la planificación de Sprint. A medida que surgen problemas, pueden ser necesarios cambios en el Sprint Backlog para alcanzar el Sprint Goal del Sprint. El equipo de desarrollo colabora con el Product Owner para cambiar el Sprint Backlog en consecuencia. En resumen: un Sprint Backlog es flexible, siempre y cuando los cambios no distraigan la atención o el foco del Sprint Goal.

De todos los eventos en Scrum, el Daily Scrum en particular presenta a los Equipos de Desarrollo una excelente oportunidad para inspeccionar y adaptarse a su progreso hacia el Sprint Goal y hacer ajustes en el Sprint Backlog cuando se considere necesario.

Sobre compromisos y pronósticos

Una fuente importante de confusión proviene de versiones anteriores de la Guía Scrum. Solían explicar el Sprint Backlog como algo con lo que los equipos de desarrollo se “comprometen”. Aunque no fue así, algunos lectores tomaron esto como algo por lo que podrían responsabilizar a los equipos de desarrollo. Debido a que la intención de Scrum Framework siempre ha sido trabajar empíricamente frente a un trabajo complejo e inspeccionar y adaptarse en todo el Sprint, la guía ahora describe el Sprint Backlog como un “pronóstico” por parte del Equipo de Desarrollo del trabajo necesario para lograr el objetivo de Sprint al entregar un incremento “Terminado”. Está perfectamente bien, incluso natural que los de Sprint Backlog cambien durante el Sprint a medida que los Equipos de Desarrollo aprenden más sobre lo que se necesita y se adaptan en consecuencia.

Aunque los equipos de desarrollo no se comprometen con el Sprint Backlog, hay muchas cosas a las que se si comprometen:

• Se comprometen a hacer lo mejor que puedan para lograr el Sprint Goal;
• Se comprometen a entregar software de trabajo y de alta calidad;
• Se comprometen a inspeccionar y adaptarse continuamente;
• Se comprometen a colaborar con quien sea que necesiten colaborar durante los Sprints para lograr el Sprint Goal;
• Se comprometen con los valores del marco de Scrum;

Otra forma de ver el Sprint Goal y el Sprint Backlog es esta; donde el Sprint Backlog es la salida esperada (output), el Sprint Goal es el resultado (outcome) deseado que los Equipos Scrum quieren lograr. En lugar de tratar de meter todo lo que puedan en un Sprint, el objetivo de los Equipos Scrum es alcanzar el resultado (outcome) deseado (el Sprint Goal) con la menor cantidad de salida (output) (Sprint Backlog).

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Consejos

Entonces, ¿qué puede hacer para ayudar a los Equipos Scrum a trabajar de manera efectiva con su Sprint Backlog? Ayuda a adoptar la naturaleza emergente del Sprint Backlog. En lugar de tratar de mantener estable el Sprint Backlog aliente a los Equipos de Desarrollo a cambiar, refinar y mejorar los Items a medida que avanzan. Si se descubre un nuevo trabajo, el equipo de desarrollo lo agrega al Sprint Backlog. Si el trabajo resulta innecesario, se elimina. Depende del equipo de desarrollo realizar estos cambios y colaborar con el Product Owner cuando sea necesario. Los cambios realizados en el Sprint Backlog siempre se realizan con el propósito de lograr el Sprint Goal mediante la entrega de un Incremento “Terminado”.

Conclusiones

En esta publicación abordamos el mito de que el Sprint Backlog no cambia durante el Sprint. Utilizamos la Guía Scrum como referencia y explicamos la diferencia entre “compromisos” y “pronósticos”. ¿Cuál es tu opinión sobre este mito? Siempre estamos ansiosos por aprender de su experiencia.

Si quieres aprender en idioma español tenemos varias fechas por Centroamérica y Sudamérica en alianza con CeaSoft y Agile611 ambos partners de Scrum.org. Al lado derecho puedes visualizar rápidamente algunas fechas de las planificadas.

Para ver todas las fechas pincha en el botón de abajo ver calendario