Scrum: ¿Qué es el Product Backlog?

El product backlog (o pila de producto) es un listado de todas las tareas que se pretenden hacer durante el desarrollo de un proyecto.

Algunos product backlog pueden asociarse con proyectos de varios años, incluso.

Todas las tareas deben listarse en el product backlog, para que estén visibles ante todo el equipo y se pueda tener una visión panorámica de todo lo que se espera realizar.

¿Qué tan extenso puede ser?

Si el proyecto o producto amerita una lista larga, podemos tener cientos o miles de actividades en el product backlog.

Nosotros asignamos prioridades sobre el product backlog, en base a las necesidades del cliente y la complejidad de cada actividad.

Así mismo, de forma sucesiva, cada sprint produce detalles adicionales, en el diseño, en la funcionalidad, y la verificación de actividades.

Hasta aquí debes tener una idea general del concepto. Pero si realmente te interesa, continúa leyendo.

El product backlog en Scrum es una lista de características que han sido priorizadas, y contiene descripciones breves sobre todo lo que se desea para el producto que se va a desarrollar.

Cuando aplicamos Scrum, no es necesario definir todos los requisitos al inicio de un proyecto. Típicamente, el product owner en conjunto con el equipo empiezan escribiendo todo lo que consideran importante en el product backlog.

Este product backlog es casi siempre suficiente para iniciar con el primer sprint. Y este product backlog tiene permitido crecer y cambiar tanto como sea necesario, en función a lo que se va aprendiendo sobre el producto y los clientes.

Usualmente este listado comprende diferentes tipos de elementos:

1. Features
2. Bugs
3. Technical work
4. Knowledge acquisition

¿Cómo se redactan los elementos que van en el Product Backlog?

La forma predominante en un equipo que usa Scrum, es expresar las características en forma de user stories (historias de usuario), que son breves descripciones de la funcionalidad que se desea, contadas desde la perspectiva del usuario. Un ejemplo es:

"Como comprador, yo puedo revisar los productos que están en mi carrito de compras antes de confirmar mi compra, y así estar seguro de lo que he seleccionado"

¿Se pueden considerar bugs en el listado?

Sí, de hecho "bugs" aparece como uno de los tipos de elementos que un product backlog puede tener, y que antes mencionamos.

Los bugs se pueden incluir en el product backlog a medida que se detectan. Pero si un sprint no ha finalizado, y la historia de usuario correspondiente está en desarrollo, no es necesario crear una actividad nueva para dar solución al inconveniente, a menos que implique varios cambios.

Todas las actividades se deben considerar

El trabajo técnico y las actividades para adquirir nuevo conocimiento también se consideran en el product backlog. Un ejemplo de trabajo técnico sería, "Actualizar el equipo de todos los desarrolladores a Windows 10". Y un ejemplo de adquisición de conocimiento podría ser investigar y comparar librerías de JavaScript y hacer una elección.

Del product backlog a los sprint backlogs

El product owner se presenta en el sprint planning meeting con el product backlog priorizado y describe los items principales al equipo.

El equipo determina qué items pueden completar durante el sprint que está por iniciar. El equipo mueve los items desde el product backlog al sprint backlog correspondiente.

Al hacerlo, ellos expanden cada item del product backlog en una o más tareas (sobre el sprint backlog). Así el equipo puede compartir el trabajo de forma más efectiva durante el sprint.

No existe un orden estricto

Idealmente, el equipo empieza con los primeros elementos del product backlog priorizado, y trazan una línea respecto a los items que se implementarán luego (próximos sprints). Pero en la práctica, no es necesario seguir ese orden. Por ejemplo, es común ver que se seleccionen los primeros 5 items con más prioridad y luego 2 items con baja prioridad, pero que están asociados con los primeros 5.

¿Podemos usar kanban?

Tanto el product backlog como los sprint backlogs pueden usarse en conjunto con “kanban”. Kanban funciona como un pull system (mas no como un push system).

• En un push system, el Scrum Master asigna nuevas acitividades e indica cuáles deben ser realizadas.
• En un pull system, los miembros del equipo seleccionan las tareas, para trabajar en ellas.

# scrum # agile