Hoy volvemos a la carga con la segunda entrega sobre los artefactos en Scrum: el Sprint Backlog (dejo por aquí el enlace a la primera entrega sobre Product Backlog). Este artefacto, que cualquier equipo Scrum usa en su día a día, es uno de los grandes desconocidos. No son pocos los debates que se mantienen al respecto sobre a quién pertenece, qué debe contener, cuál es su finalidad, etc. En esta entrada intentaremos arrojar luz sobre estos temas y comentar algunas de las buenas prácticas que deberíamos tener.
¿Qué es el Sprint Backlog?
El Sprint Backlog no deja de ser un conjunto de tareas del Product Backlog que se han seleccionado para el Sprint (por ello, esta denominación especial). Si vamos un poco más allá de esta definición básica encontraremos que el Sprint Backlog es realmente un plan. Un plan para entregar incremento de producto (otro artefacto, lo veremos en siguientes entregas) y, por supuesto, alcanzar el objetivo de Sprint (Sprint Goal).
Otra definición que se le podría dar es la de «previsión». Una previsión de qué funcionalidades estarán en el próximo increment y, dependiendo de la definición de «done» del equipo, esté disponible como software funcionando de una forma u otra.
Fuente: Scrum.org
Buenas prácticas
A continuación enumeramos diferentes consejos y/o buenas prácticas a la hora de crear y gestionar el Sprint Backlog:
- Se recomienda incluir al menos una acción que haya salido de la retrospectiva del Sprint anterior que pueda tener un gran impacto en el proceso del equipo. De esta forma, nos aseguraremos de cumplir con uno de los pilares básicos de Scrum de inspeccionar y adaptar. Comúnmente las acciones se intentan cumplir en paralelo a la ejecución del Sprint, pero la realidad es que la mayor parte de las veces no se llegan a cumplir. El día a día o un Scrum Master que no vela porque estas acciones se vayan implementando en tiempo y forma (en su labor de conseguir y optimizar todo el proceso Scrum) son los principales motivos que hacen que estas acciones caigan en saco roto.
- Debe ser la herramienta central sobre la que se desarrolle la Daily. El Sprint Backlog debe tener los detalles suficientes como para que todo el equipo entienda los cambios y progresos realizados y enfocar las daily como, digamos, «mini-plannings», donde revisar si sigue siendo alcanzable o no el objetivo del Sprint o es necesario acciones para asegurar esto.
- Siguiendo la práctica anterior, el equipo debe ir gestionando las prioridades con el foco en conseguir cumplir el objetivo del Sprint. Por ello, tiene la potestad para modificarlo durante el Sprint en caso de que se detecten nuevas necesidades o nuevos aprendizajes sobre el trabajo a realizar para conseguir este objetivo. Esto siempre ha sido un tema entre la polémica y el debate, pero a día de hoy, lo que nos indica la guía Scrum es que el equipo de desarrollo es el único que puede modificar el Sprint Backlog durante el Sprint. Es más, indica que pertenece únicamente al equipo de desarrollo.
- En esta línea, si el equipo de desarrollo detecta que un trabajo no incluido en este artefacto es necesario para conseguir el objetivo, debe añadirlo. Y en el lado opuesto, si el equipo acuerda que hay trabajo del Sprint que ya no es necesario para conseguir el objetivo, puede y debe eliminarlo. De esta forma, se asegura por el propio equipo que el trabajo a realizar durante ese Sprint es justo el necesario para cumplir el Sprint Goal, adaptándose a los cambios que vayan surgiendo.
- El equipo debe tener total visibilidad sobre este artefacto y, más allá de medir la famosa velocidad o cuanto estamos entregando, es importante medir la cantidad de trabajo pendiente. En las dailys se tendrá que ir actualizando el progreso y elegir según trabajo restante, días del Sprint y objetivo. Por ello, es importante tener siempre actualizado este backlog, ya que determinará los siguientes pasos día tras día.
Conclusión
Hemos visto la gran relación que existe entre este artefacto y el objetivo del Sprint (del que hablaremos en futuros posts). Todas las piezas de la máquina que forman el marco de trabajo Scrum son importantes y el proceso completo solo funcionará si se implementan y se usan correctamente. Como resumen, el Sprint Backlog es un artefacto muy potente por y para el equipo y, como todos sabemos, «un gran poder conlleva una gran responsabilidad».