Índice
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.
Si tenes alguna consulta o te resultó útil, dejame tu comentario abajo.
Soy emprendedor (cofundador de ITtude) apasionado por la Agilidad, Scrum y el desarrollo de software. He dictado más de 40 entrenamientos y capacité a más de 1000 personas en Scrum y Agilidad.
Estoy certificado como Scrum Trainer (ST) by Scrum INC, (por Jeff Sutherland, cofundador de Scrum) y como CSP-SM, CSP-PO, CSD y CAL por la Scrum Alliance. Coach profesional por ICF.
EXCELENTE INFORMACIÓN
Muchas gracias Katy!
Siempre muy util todo lo que aportan!! Gracias
Aprecio mucho tu comentario. Muchas gracias!
Gracias!!! Me cuesta pensar en como arman el o los primeros Sprint Backlog sin información de la velocidad o capacidad.
Si el equipo es totalmente nuevo y son sus primeros Sprints, al no tener una velocidad medianamente precisa, desde mi punto de vista, es mejor enfocarse en establecer un buen Sprint Goal que gastar mucho tiempo en estimaciones. Recordemos que Scrum se basa en el empirismo, por lo que sus indicadores van a tener más sentido a medida que el equipo comienza a trabajar junto y conocer su contexto.