El Product Backlog

El Product Backlog

En Scrum, el Product Backlog, o Pila de Producto, o Lista de Producto, es, valga la redundancia, reflejo del producto que pretendemos crear.

Podemos compararlo con el catálogo de requisitos de toda la vida, o con el catálogo de casos de uso. Sea como fuere, debe recoger todas las funcionalidades que describen el producto.

Pero además debe registrar todas aquellas tareas técnicas relacionadas con la construcción de dicho producto. Por tanto, el Product Backlog va más allá de los requisitos de negocio, de forma que podemos considerar que todo aquello que no aparezca en el Backlog directamente no existe.

Unificar y centralizar todo lo relacionado con un producto en un único documento (artefacto, le llama la Guía) tiene una enorme ventaja de cara a la transparencia. Se acabó eso de te lo indiqué en un correo, o aquello de eso está recogido en una excel en el repositorio, o eso otro de yo ya lo dije en aquella reunión

Insisto: lo que no está en el Product Backlog no existe.

Por tanto, ya que el Product Backlog o Lista de Producto es la representación viva del producto, hay que procurar saber darle el tratamiento adecuado, ya que un mal Backlog conducirá inevitablemente a un mal producto.

Antecedentes del Product Backlog

Hemos acabado las sesiones de Design Thinking y las del Sprint 0 y todo el mundo tiene claro qué se espera del proyecto que va a comenzar. Es más, tenemos incluso un prototipo navegable que, pantalla a pantalla, nos va mostrando el aspecto que tendrá el producto final y las distintas acciones que podrán realizarse con él.

Nunca insistiré lo suficiente en la importancia de un buen prototipo navegable. Que una imagen vale más que mil palabras es una verdad indiscutible de modo que, si quieres trasmitir fácilmente al DevTeam, a un cliente, a la gerencia o a quien sea qué hace tu producto, asegúrate de contar con un prototipo navegable que sea un fiel reflejo de lo que, meses después, será el producto final.

Es más, las pantallas de ese prototipo serán la plantilla sobre la que trabajará el DevTeam. En mi experiencia con equipos de desarrollo he podido comprobar que muchas veces los desarrolladores ni se molestan en leer las historias de usuario a la hora de abordar su construcción, sino que se guían por las pantallas del prototipo.

Por tanto, no escatimes en un buen UX que haga del prototipo una herramienta fundamental y base para la creación del Product Backlog y el desarrollo del producto.

Creo que ya te quedó claro que el Product Backlog debe ir de la mano del prototipo y viceversa. A medida que vayas dando forma al Product Backlog comprobarás que determinados aspectos del prototipo no son los adecuados y esto te obligará a readaptarlo y perfeccionarlo, siempre buscando que éste sea fiel reflejo del producto final.

Qué es el Product Backlog Scrum

Al final, un Product Backlog no es ni más ni menos que una pila priorizada de requisitos o necesidades de negocio. Así de simple.

Bastaría por tanto con un Excel para reflejar tu Product Backlog, tal que en lo alto de la pila estén los requisitos o ítems de mayor valor de negocio y a medida que vas bajando en la pila se irán mostrando los de menor valor de negocio o aquellos que, por su alta incertidumbre o coste, no tiene sentido priorizar.

Recuerda que es el Product Owner quien determinará la prioridad de estos requisitos ya que él sabe mejor que nadie qué aporta más valor a la compañía o al cliente. O por lo menos, debería.

Además, los requisitos más prioritarios serán los mejor definidos, los más claros para el equipo y, en definitiva, los que presenten menor incertidumbre. A medida que vayas bajando en el Product Backlog los requisitos estarán menos definidos y tendremos menos detalle sobre ellos.

Es importante que entiendas que la prioridad de un requisito no sólo la determina el valor que aporta al cliente, sino también en qué grado es factible desarrollarlo o no.

Por ejemplo, una determinada funcionalidad podría dar un valor enorme a un producto, pero si la posibilidad de abordarla es remotísima ya que su construcción supondría un absoluto arco de iglesia, está claro que tal vez no puedas tenerlo entre las tareas a realizar a corto plazo.

Insisto en que el Product Owner debe tener la finura para encontrar el equilibrio entre aquello que aporta valor, es factible y la relación coste-beneficio es la adecuada. Ya abordaremos el tema de la priorización en otro post, porque tiene mucha miga.

Por algo el rol de Product Owner es el más delicado dentro de Scrum…

Tipos de ítems que puede tener un Product Backlog

Los ítems del Product Backlog (o PBIs) son los posibles elementos que conforman el Product Backlog. Básicamente hay 3 tipos de PBIs:

Historias de Usuario o User Stories

Las Historias de Usuario son los requisitos de negocio que crea el Product Owner o alguien en su nombre, pero sea quien sea quien los cree es el Product Owner responsable de ellos. Son los PBIs más importantes, ya que contienen las necesidades del negocio y son, en definitiva, los que dan sentido al producto que se va a desarrollar.

Por ejemplo, en una aplicación de comercio online, una posible historia de usuario sería:

Como cliente quiero poder pulsar sobre el icono carrito para poder ver el contenido de éste y que se me muestren por pantalla todos los productos que tengo seleccionados

Las historias de usuario contendrán normalmente los llamados criterios de aceptación, que serían las condiciones que deben cumplirse para que la historia pueda considerarse terminada (ver concepto de Definition of Done).

Mediante los criterios de aceptación damos detalle a la funcionalidad que deberá cubrir la historia de usuario. Por ejemplo, un posible criterio de aceptación de la anterior historia sería:

Los productos deberán mostrarse en orden cronológico, desde los más recientemente seleccionados hasta los más antiguos

Una Historia de Usuario debe tener un tamaño que permita completarla en un solo Sprint.

Historias Técnicas

Son requisitos técnicos, trabajo que no se puede traducir como requisito de negocio pero que es necesario para el desarrollo del producto. Por ejemplo, una posible historia técnica podría ser:

Instalar un sistema de integración continua

En plataformas como Jira puedes encontrarte estos ítems con el nombre de Operational Tasks.

Errores o Bugs

Son incidencias que se han ido detectando en el producto sprint tras sprint y que deben quedar perfectamente informadas en el Product Backlog. Recuerda que el Backlog debe ser un reflejo lo más exacto posible del producto en tiempo real.

Las incidencias podemos dividirlas en incidencias asociadas a una historia de usuario en particular, por ejemplo:

Al pulsar en el icono del carrito, cuando éste excede de 10 productos no me muestra nada más que los 10 primeros

O incidencias técnicas generales del producto, del estilo:

Cuando se conectan más de 100 personas a la aplicación se produce un time-out

En Scrum, la gestión de bugs tiene sus peculiaridades. Trataremos el tema de los bugs en un punto aparte.

Las Épicas

Las Historias de Usuario pueden agruparse en superhistorias o grandes funcionalidades llamadas épicas o epopeyas. Un nombre un poco rimbombante para describir lo que sería una funcionalidad grande que puede subdividirse en funcionalidades más manejables que serían las Historias de Usuario.

Por ejemplo, las siguientes cuatro Historias de Usuario:

  1. Como usuario quiero poder ver el contenido de mi carrito
  2. Como usuario quiero poder eliminar individualmente productos de mi carrito
  3. Como usuario quiero poder vaciar por completo mi carrito
  4. Como usuario quiero poder dar orden de compra desde mi carrito a los productos que seleccione para ello

Podrían agruparse en una épica que sea:

Gestionar mi carrito

A mí personalmente me basta con estos 4 posibles PBIs: Épicas (conjunto de Historias de Usuario), Historias de Usuario, Historias Técnicas y Bugs. Pero hay quien le gusta rizar el rizo y añade más tipos de ítems:

  • Tema: un tema engloba varias épicas relacionadas, sería algo así como una super-épica. Por ejemplo, para un sistema ERP podríamos tener un tema que sea Módulo de RRHH que incluya las épicas Módulo de Gestión Personas, Módulo de Selección, Módulo de Prevención de Riesgos Laborales y Módulo de Beneficios Sociales.
  • Feature: podríamos traducir este término por funcionalidad, es decir, una operación que para completar todos los casos podría necesitar más de una historia de usuario. Por tanto, podríamos considerar la feature una mini-épica. Siguiendo con el ejemplo anterior, dentro de la épica Módulo de Beneficios Sociales podría existir un submódulo que sea Gestión de Fiscalidad y del que cuelguen n historias de usuario.

Otros ítems del Backlog

Aunque los ítems de un Product Backlog se pueden clasificar en las tres categorías simples citadas anteriormente, Historias de Usuario (requisitos de negocio, que podemos agrupar por épicas), Historias Técnicas (requisitos técnicos ajenos al Product Owner) y Bugs (tanto funcionales como técnicos), existen dos tipos de PBIs que tienen un significado per se aunque tú después los etiquetes dentro del Backlog como Historia de Usuario o Historia Técnica. Son los spikes y la deuda técnica.

Estos dos puntos los veremos en sus correspondientes apartados. Pero podemos resumir que los spikes representan esfuerzo dedicado a investigar.

Por otra parte, la deuda técnica hace referencia al esfuerzo para mejorar una solución cortoplacista en la que incurrieron los desarrolladores y que terminó resintiendo la calidad del software.

En herramientas como Jira hay muchos más tipos de ítem o issue types: improvements (cambios que implican mejoras sobre una historia ya desarrollada en anteriores sprints), risks, releases, etc. Pero por ahora quedémonos con los explicados. Son más que suficientes.

Aunque me estoy adelantando, a la hora de crear el Sprint Backlog (ojo, no confundir con el Product Backlog, aunque está relacionado), vamos a necesitar un tipo de ítem más: la sub-task o subtarea y el sub-bug.

Las subtareas tienen un cariz más técnico ya que subdividen el trabajo que hay que desarrollar para completar una historia, lo que conlleva subtareas de back, front, testing, despliegue, etc.

El sub-bug es una incidencia que asociamos a una historia en particular, de tal forma hasta que no se resuelva esa incidencia la historia no podría darse por buena. El matiz de diferenciación con el bug es muy sutil y lo veremos en otro post dedicado a la gestión de incidencias.

Jerarquía de ítems del Product Backlog
Jerarquía de ítems del Product Backlog

Reflexión final

El Product Backlog es el documento rey en torno al que trabajará todo el Equipo Scrum. Por tanto, deberás poner el debido cuidado para que no tenga la menor fisura en lo que a transparencia se refiere.

Si eres Product Owner qué te voy a decir, tienes un importante trabajo entre manos. Ponle todo el esfuerzo que requiera y no escatimes en ello. Ten presente los atributos INVEST y apóyate siempre en tu Scrum Master.

Si eres Scrum Master vigila siempre que el Product Backlog no se desvía de lo que se está desarrollando y que siempre refleja en tiempo real el estado del proyecto y del producto. A veces, el Product Owner y el Equipo de Desarrollo remolonearán a la hora de tenerlo actualizado. No cedas un milímetro. Recuerda, lo que no está en el Backlog no existe.

Si perteneces al Equipo de Desarrollo no te desentiendas del Backlog. No te vayas a pensar que por ser responsabilidad del Product Owner, el mantenimiento de este artefacto no va contigo. El Product Owner no va a entrar en cuestiones de historias técnicas, o deuda técnica, o spikes,… Así que ten el Backlog actualizado con todos aquellos ítems que sean propios del Equipo de Desarrollo y mantén informado al Product Owner de todos aquellos cambios que realices sobre este documento.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario