¡Compártelo!
Share on facebook
Share on google
Share on twitter
Share on linkedin

Introducción a los artefactos Scrum: El Product Backlog

En el post de hoy me gustaría hablar sobre un elemento al que creo que no se le está dando toda la importancia que tiene dentro del marco Scrum. Todos conocemos (en menor o mayor detalle) los roles y los eventos, ¿pero dónde quedan los artefactos? Juntos se completa un cuadro que consigue que el sistema funcione. Hoy quisiera poner el foco en uno de estos artefactos: el Product Backlog (o backlog de producto). Como siempre, la información oficial la podrás encontrar en la Guía oficial de Scrum. Definir qué es el Product Backlog es algo, a priori, sencillo. Es una lista de cosas. Simple, ¿no? Profundicemos.

¿Qué «cosas» componen el Product Backlog?

Estas «cosas», a las que llamaremos «ítems«, pueden tener diferentes características: nuevas funcionalidades, cambios de funcionalidades existentes, bug-fixing, cambios en la infraestructura, en la arquitectura, etc. Lo importante, y una de las cosas que caracteriza a un Product Backlog, es que son ítems que el equipo quizás entregue con el objetivo de conseguir un resultado. Digo quizás porque, como a mi me gusta verlo, es una lista de deseos. Respecto al formato de estas tareas, puede ser mucho y variado, y cada equipo y organización debería adaptarlo a su contexto. El formato de las historias de usuario es solo una técnica, la cual no es siempre la mejor opción.
Ejemplo Product Backlog

Fuente: Scrum.org

 
El Product Backlog es (o debería ser) la única fuente de trabajo a realizar con la que un equipo lidia (también es frecuente encontrar varios equipos trabajando sobre el mismo backlog, pero eso da para otro post). Cualquier tarea que no esté en el backlog, no debería ser realizada. Pero, ¡ojo! La presencia de un ítem en el backlog no es garantía de que se vaya a ejecutar y entregar. Una de las principales características de un backlog es que es dinámico. Debería (es el objetivo) ocurrir que añadir y quitar ítems a un Product Backlog fuera rápido y, sobre todo, barato. Es por ello que una correcta ordenación y priorización es fundamental. Recuerda que, por el contrario, en el Sprint Backlog (otro artefacto del que hablaremos en post futuros) no debería haber cambios no justificados durante la ejecución del Sprint.
Por otro lado, un backlog no tiene por qué ser completo y ni mucho menos cerrado. En el estricto sentido del concepto realmente un Product Backlog nunca está completo. Un equipo no tiene por qué esperar a que esté todo perfectamente definido en el backlog (en ese caso estaríamos ejecutando una fase clásica de una metodología en cascada). Puede empezar a trabajar con una idea inicial e ir dándole forma al resto del backlog que está por venir según vayamos progresando. Lo ideal es ir definiendo e hilando cada vez más fino conforme se acerca el momento del desarrollo. Aquellas tareas que, por su incertidumbre, tienen un tamaño considerable no deberían entrar en el flujo de desarrollo en el corto plazo.

¿Qué incluir en tu backlog?

Entonces, ¿no habrá demasiadas cosas en mi backlog? Es posible. Si el tamaño es excesivo será mucho más complicado de gestionar, lo que puede derivar en mucho desperdicio (principio Lean). Esto puede ocurrir si se empiezan a agregar todas las nuevas ideas que vayan surgiendo (lo cual está muy bien), pero no se exploran estas ideas ni se eliminan aquellas que ya se han visto. Otro motivo puede ser no eliminar aquellos ítems que sabemos que nunca se terminarán realizando, independientemente del motivo. Y el mayor motivo de todos: dividir en tareas pequeñas aquellas más grandes con demasiada antelación a cuando el equipo trabajará en ellas. Conseguir el tamaño perfecto de backlog no es fácil y recae en el Product Owner, ya que es el responsable de gestionarlo.
product backlog
 

¿Dónde mostrar el Product Backlog?

Generalmente un Product Backlog siempre se ha volcado sobre un elemento físico, de tal manera que siempre fuera visible y compartido por todo el equipo, ya sea en una pizarra o en una pared. Esta responsabilidad, de nuevo, recae en el Product Owner. Es responsable de darle la visibilidad que se merece al backlog. Con el tiempo, y sobre todo ahora que el teletrabajo está extendiéndose, las herramientas digitales han ido tomando peso. Estas herramientas permiten conocer mucha más información de la que, quizás, puede darte un tablón. Lo importante es que exista y sea visible para todos. El objetivo es que los ítems de este backlog sean al final conversaciones para conseguir aportar el mayor valor posible al usuario.
Por ello, es tarea (y no fácil) que este artefacto esté siempre en constante refinamiento. Conforme más vayamos aprendiendo de esas tareas iniciales, mejor entendimiento de las necesidades del producto.

Artículos relacionados

Automatizando tareas mediante Slack Bots

Automatizando tareas mediante bots en Slack

En el mundo en el que vivimos actualmente, cada vez es más necesario automatizar tareas que resulta tedioso realizarlas de forma manual, desde pruebas funcionales de una aplicación, a envío de emails o casi cualquier tarea que se nos pueda ocurrir. Es por eso que

Sprint Backlog

Artefactos Scrum: el Sprint Backlog

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). Este artefacto, que cualquier equipo Scrum usa en su día a día, es uno de los grandes desconocidos. No son

Qué es kanban portada

Qué es Kanban y cómo aplicarlo al desarrollo de software

Últimamente no paramos de oír hablar sobre Kanban en desarrollo de software. Pero ¿sabes qué es Kanban y cómo implementarlo? Kanban es un método flexible de gestión del trabajo visual, que evoluciona según las necesidades del equipo.  Lo creó David J. Anderson en Japón a