Definición del SPRINT BACKLOG

El Sprint Backlog es la suma de todos los elementos del Product Backlog elegidos para el Sprint, más un plan de cómo crear el Incremento de Producto que permita alcanzar el Sprint Goal (Objetivo del Sprint). Es uno de los 3 artefactos de Scrum y es el que se construye durante la segunda parte de la Sprint Planning.

El equipo generalmente subdivide este trabajo en elementos llamados Sprint Backlog Ítems (SBI). Estos elementos pueden representar tareas que el equipo debe completar, bloques de construcción intermedios que se combinan en una entrega, o cualquier otra unidad de trabajo que ayude al equipo a comprender cómo lograr el Sprint Goal dentro del Sprint.

Visibilidad del avance del Sprint

Es importante que este artefacto este visible para todo el equipo, ya que tiene como objetivo proporcionar transparencia sobre el estado del trabajo planificado para el Sprint. Es por esta razón que me gusta llamarlo un radiador de información.

El equipo de desarrollo realiza un seguimiento del trabajo total restante al menos una vez por día en la Daily Scrum para proyectar la probabilidad de lograr el Sprint Goal. Al reconocer el trabajo restante a lo largo del Sprint, el Equipo de Desarrollo puede administrar su progreso.

Tablero Kanban

Si bien la guía Scrum no define como implementar este artefacto, creo que una manera recomendada de hacerlo es a través de la implementación de un tablero Kanban.

El tablero Kanban es una herramienta compuesta por columnas para representar el estado de una tarea y filas que representan diferentes tipos de actividades (por ejemplo tareas descompuestas de las Historias de Usuario).

Cada tablero de Kanban tiene al menos tres columnas con estados base:

•  «To Do» / Por hacer (punto de entrada de una tarea)
• «W.I.P» / Trabajo en proceso
• «Done» (Terminado)

Si bien soy partidario de tener este artefacto de manera física para fomentar la comunicación cara a cara, hoy en día, existen soluciones de tableros Kanban digitales como Trello muy buenas en especial para equipos remotos.

A este tablero se le pueden agregar más columnas como por ejemplo «QA» (En etapa de pruebas). A continuación un ejemplo de nuestro tablero para uno de nuestros talleres:

Ejemplo

¿Quién es el responsable del SPRINT BACKLOG?

El Sprint Backlog pertenece únicamente al Equipo de Desarrollo. El equipo de desarrollo modifica este artefacto durante todo el Sprint. Este surgimiento ocurre cuando el Equipo de Desarrollo trabaja a través del plan y aprende más sobre el trabajo necesario para lograr el Sprint Goal.

Cuando los elementos del plan se consideran innecesarios, se eliminan. Solo el Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint.

La diferencia entre Product Backlog y SPRINT BACKLOG

El Sprint Backlog se crea durante el evento de Sprint Planning. Se compone de los elementos seleccionados de la parte superior (lo más prioritario) del Product Backlog que se consideran necesarios a realizarse para cumplir el Objetivo del Sprint y que el Equipo de Desarrollo cree factible terminar según su velocidad y capacidad.

Para determinar cuántos PBIs incluir en el Sprint Backlog nos basamos en la velocidad de los últimos Sprints del Equipo de Desarrollo.

¿Asignar tareas?

Los SPIs no se asignan o pre-asignan en Scrum. Hacer esto fomenta que el equipo baje su responsabilidad compartida sobre el Objetivo del Sprint, ya que cada persona se siente más responsable por cumplir sus SPIs asignados (tareas, etc) que en contribuir al cumplimiento del Objetivo del Sprint.

Otra contra que observo en pre-asignar tareas es que el equipo baja su nivel de auto-organización y comunicación para resolver problemas y crear un incremento de valor.

---