El Sprint Backlog es un plan que elaboran los desarrolladores durante la Sprint Planning, los desarrolladores son quién realmente hacen el trabajo y por lo tanto quien debe de crear dicho plan. Y nadie debe de asignarles tareas ni Product Owner y tampoco el Scrum Master.
Como beneficios de un buen Sprint Backlog podemos encontrar el aporte de la transparencia en todo momento, transparencia sobre el trabajo realizado y sobre todo la cantidad de trabajo que falta por hacer para poder alcanzar el Sprint Goal.
Indice de contenidos
Ejemplos de Sprint Backlog
No hay un estándar sobre como tener un Sprint Backlog, pero sí que podemos realizar algo parecido a la foto siguiente:
Para poder crear algo así durante la Planning, podemos realizar las siguiente preguntas:
- ¿Con qué elementos podemos empezar?
- ¿Cuál dejar para el final del Sprint?
- ¿Hay algunas dependencias internas, técnicamente o funcionalmente?
- ¿Existen algunas dependencias externas que no están resueltas y que pueden llegar a bloquear el avance de algún PBI?
- ¿Qué tareas del primer PBI hay que abordar?
- ¿Quién del equipo puede acometer esas tareas?
- ¿Tiene sentido que trabajemos en varios PBIs a la vez? ¿o mejor poner foco en uno y luego el otro?
- ¿Tiene sentido hacer Pair Programming en todos los PBIs?
- ¿Tiene sentido hacer Mob Programming en algunas de las tareas?
- etc.
No hay un único plan para todo, lo importante es buscar la manera de crear un plan según el objetivo que tiene el equipo y sobre todo ser capaces de inspeccionar y adaptar el Plan Daily a Daily
Quien debe gestionar el Sprint Backlog
El Sprint Backlog es propiedad de los developers en el Scrum Team, nadie más que ellos puede añadir, quitar o modificar PBIs en este artefacto. ¿Esto quiere decir que podemos cambiar el contenido del Sprint Backlog durante el Sprint una vez arrancado? pues si.
¿Puede cambiar el Sprint Backlog durante el Sprint?
En el mundo del desarrollo de software la incertidumbre está al orden del día, desconocemos más que conocemos. Y es muy normal que el equipo descubra cosas que no tenía claras, aprenda cosas nuevas, o simplemente, se dé cuenta que algo que pensó al principio que era fácil resulta que es complicado o al revés.
Hay que pensar que es posible que después de la planning el equipo se dé cuenta que se les olvidó una feature importante y necesaria para alcanzar el Sprint Goal (este si que no debe cambiarse, su alcance si), entonces lo que tienen que hacer es renegociar el alcance con el Product Owner y ajustar su Sprint Goal.
Al final el equipo conforme va aprendiendo durante el sprint, puede eliminar, añadir o modificar ciertos PBIs. Y solo los desarrolladores pueden hacerlo, ni el PO ni el SM tienen que gestionar el Sprint Backlog del equipo.
La adaptación y el Sprint Backlog
Creo que ya queda claro que el Sprint Backlog debe de inspeccionarse y debe de adaptarse durante el Sprint, pero, ¿Que hay que inspeccionar? ¿Cómo hay que hacer? y ¿Cuándo hay que hacerlo? vamos paso a paso.
El Sprint Backlog se crea en la Sprint Planning e incluso ahí se puede adaptar conforme se esté creando el Plan para alcanzar el Objetivo del Sprint. Otro evento ideal para inspeccionar y adaptar el Sprint Backlog es el Daily Scrum, para ello es importante que el Sprint Backlog ofrezca una imagen real del estado del Sprint para conseguir el objetivo.
Cuando el Sprint Backlog ofrece una foto real de la situación del Sprint y el progreso del equipo, permite a los desarrolladores ajustar y adaptar lo que consideran necesario para aumentar la probabilidad de alcanzar sus objetivos, estas actualizaciones pueden ser como:
- El trabajo que se ha terminado o el que se está empezando
- Los items que se han bloqueado
- Algún trabajo que se acaba de identificar
- Elementos que por varios motivos se consideran no necesarios para el Sprint
- Algún tipo de riesgo que se identifica
- etc.
Estos ajustes se realizan para poder alcanzar el Sprint Goal como equipo.
Más info sobre Sprint Backlog en ScrumdotOrg
Si te ha gustado, dale a me gusta y ayudame a compartirlo 🙂
Un saludo y hasta la próxima
