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.
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.
¿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.