Product Backlog y Sprint Backlog en Scrum

La metodología Scrum no se puede entender sin el Product Backlog y el Sprint Backlog, dos de los artefactos con los que el equipo Scrum se organiza para sacar adelante el trabajo y obtener un buen resultado final.

Del diseño de dos buenos Product Backlog y Sprint Backlog depende parte del éxito de un proyecto Scrum. En este artículo te enseñaremos en qué consisten estos documentos y los trucos para crearlos y alcanzar el éxito.

¿Qué es un backlog?

‘Backlog’ se traduce al español como ‘pendiente’ o ‘acumulado’. En el contexto de las metodologías ágiles, backlog es, citando a la Guía Scrum, «una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo realizada por el Equipo Scrum».

En la metodología Scrum en concreto, el Product Backlog y el Sprint Backlog cumplen funciones relacionadas con dichas tareas, que se han de ejecutar para entregar un producto o servicio que satisfaga a clientes y mercados.

Product Backlog

En Scrum, el Product Backlog es la lista de tareas pendientes y organizadas por prioridad para alcanzar el entregable final. El equipo Scrum ejecuta estas tareas en sprints, acumulables y complementarios a los sprints anteriores.

Gracias a esta lista, el equipo Scrum tiene visibilidad sobre lo que hay que hacer y los plazos para conseguirlo. Para ello, el Product Backlog se representa de forma gráfica en un tablero en el que se muestra el trabajo en marcha y su estado. Dicho tablero se puede personalizar con más categorías, según las necesidades o forma de trabajar de cada equipo.

Elementos del Product Backlog

El Product Blacklog está formado por diversos elementos que enriquecen la lista de tareas pendientes: historias de usuario o user stories, historias técnicas y errores o bugs.

Historias de usuario

Aunque no están recogidas en la guía Scrum, es común utilizar las historias de usuario o user stories son funcionalidades o tareas que se deben hacer en un sprint. Como dice el nombre, hay que verlas desde el punto de vista de usuario; es decir, al redactarlas (y lo recordaremos en el apartado ‘Cómo crear un Product Backlog’), tenemos que pensar en las necesidades del usuario que se buscan cubrir con el entregable final: facilitar su día a día, mejorar sus momentos de ocio…

Con ese objetivo en mente, las historias se redactan como peticiones que ellos tienen. Por ejemplo, una tarea podría ser: «En cada página de producto de este e-commerce, necesito ver con facilidad sus diferentes características (colores, modelos, tamaños) para comprar el que más se ajusta a mis deseos».

Historias técnicas

Las historias técnicas son necesidades técnicas para el cumplimiento de un proyecto. No son tareas para hacer, sino exigencias del proyecto para que siga adelante. No tienen valor directo para el usuario, aunque aporta valor a la solución o producto, y el equipo Scrum debe ejecutarlas para que aquel disfrute del entregable final.

Por ejemplo:

• Crear la arquitectura del producto o servicio
• Aprender a manejar un nuevo software para cumplir con una tarea del sprint.
• Crear índices en la base de datos para que las consultas vayan más rápidas.

Errores

Los errores o bugs son fallos que se detectan durante el desarrollo del proyecto Scrum y que hay que anotar con detalle en el Product Backlog.

[cp_popup display=»inline» style_id=»103782″ step_id = «1»][/cp_popup]

Cómo crear un Product Backlog

Debido a la importancia de este documento, es ideal crear y mantener un Product Backlog fácil de usar y de manejar por cualquier persona del equipo Scrum. A continuación, te damos algunos trucos para conseguirlo:

• Como hemos dicho antes, redacción sencilla y desde el punto de vista del usuario.
• Priorización y división en tareas asequibles. Algo básico en el Product Backlog de Scrum es ordenar las tareas según la necesidad en su realización. Esta priorización puede variar a lo largo de los sprint, según cambien las obligaciones.

Al trabajar en iteraciones, el backlog se va abordando en ciclos (sprints) que permitan al equipo enfocarse en cada uno de ellos y no vean la tarea final como algo difícil de alcanzar.

• Añadir solo entradas realmente necesarias. Al incluir una historia de usuario / user story, una historia técnica o un error / bug, siempre hay que preguntarse si ayuda a conseguir el entregable final. Con el desarrollo del proyecto, también puede pasar que se eliminen algunas entradas.
• No preocuparse por el nivel de especificación de todas las tareas. Puedes esbozar las menos urgentes (que a lo mejor cambian cuando llegue el momento de ejecutarlas) y profundizar en las prioritarias. Conforme las primeras ocupen posiciones superiores, detalla más al equipo lo que hay que hacer con ellas.
• Incluir los conocimientos técnicos que los miembros del equipo consigan durante los sprints, así como las mejoras también técnicas que se apliquen al entregable en las diferentes fases.

Refinamiento del Product Backlog

El refinamiento o refinement del Product Backlog es, según la Guía Scrum 2020, «desglosar y definir aún más los elementos en elementos más pequeños y precisos. Se trata de una actividad continua para añadir detalles, como la descripción, el orden y el tamaño. Los atributos suelen variar según el ámbito de trabajo».

El refinamiento no es un evento en sí, sino una mejora del Product Backlog conforme el equipo Scrum avanza y descubre detalles, errores o problemas.

Las reuniones de refinamiento se hacen cuando los equipos lo consideren y puedan. Será el momento también para cambiar la prioridad de las tareas si es necesario.

Sprint Backlog

El Sprint Backlog es uno de los artefactos de Scrum y se diseña durante el evento Sprint Planning. Consiste en una lista de tareas decidida por el equipo Scrum, y es una parte del Product Backlog que se trabaja durante el sprint. Con ella se busca conseguir el incremento, es decir, el objetivo final de cada sprint, que se suma a los anteriores y ha de encajar con ellos. En la Daily Scrum (reunión diaria), los miembros del equipo comprueban si van por el buen camino para llegar a esa meta de sprint.

El Sprint Backlog se puede representar de forma muy visual con un tablero Scrum o Scrum board; estos se pueden crear con pizarras, una hoja de cálculo o cualquiera de las herramientas de gestión de equipos que existen, como Azure DevOps, Trello, Asana, Monday o Jira.

Una vez creados estos tableros virtuales, las tareas del sprint se colocan en columnas o listas para ver la evolución de su desarrollo. Por ejemplo, un tablero de Scrum podría tener tres columnas de tareas, encabezadas como ‘Pendientes’, ‘En progreso’ y ‘Terminadas’.

Gracias a esta parrilla tan visual, es más fácil comprobar en qué momento está el sprint y detectar posibles riesgos para no llegar al Sprint Goal.

Vídeo explicativo sobre el Sprint Backlog y el Product Backlog