El Product Backlog es la única fuente de trabajo a realizar en un producto, solo hay un Product Backlog, aunque tengamos 5 equipos Scrum trabajando en el producto. Esto permite dar transparencia sobre el trabajo de cara al equipo y de cara a los stakeholders.
Indice de contenidos
¿Qué elementos debe de contener un Backlog?
Hay que pensar que en un Backlog puede haber más cosas que historias de usuarios (en otro post hablaremos sobre lo que son), como Bugs, Requisitos, Ideas, Temas técnicos, Investigación sobre nuevas tecnologías, Incidencias, mejoras a nivel de calidad, etc.
Los elementos del Product Backlog or PBIs (antes mencionados) se consideran terminados cuando cumplen con el Definition of Done durante el Sprint, estos elementos suelen ser seleccionados en el Sprint Planning por parte del Scrum Team. Pero antes de seleccionarlos es importante que se hayan refinado estos elementos, muchos equipos suelen tener un Definition of Ready que utilizan en las sesiones de refinamientos, esto les permite a los equipos asegurar ciertos elementos en cada PBI antes de considerarlo Ready to Start.
¿Quién es el responsable del Backlog?
Si revisamos la guía Scrum podemos observar que nos habla de lo siguiente: el Product Owner es el responsable del Product Backlog y su gestión efectiva y esto incluye lo siguiente:
- Elaborar, refinar y comunicar / transmitir el Objetivo de producto (ese objetivo a largo plazo)
- Definir y compartir los items del Product Backlog o PIBs, muchas veces su creación en Jira (si usa jira para gestionar su Product Backlog).
- Ordenar y priorizar el Backlog del producto para maximizar la entrega de valor
- Velar para que el Backlog sea accesible y transparente al equipo y los stakeholders
Pero aquí hay un mito muy típico en equipos Scrum y organizaciones que utilizan Scrum. La mayoría piensan que solo el Product Owner debe realizar estas actividades. Lamentablemente esto no es cierto y además puede generar ciertas jerarquías y limitar: la motivación, creatividad y proactividad.
Todas las actividades mencionadas anteriormente la pueden hacer los desarrolladores de producto, pero el Product Owner es quien tiene la última palabra y es el único responsable, en otras palabras, si hay algo que no encaja en el Backlog, quien da la cara por ello es el Product Owner.
De hecho, muchos equipos Scrum suelen trabajar juntos para crear Items en el backlog y ordenarlos.
¿Cómo ordenar o priorizar el Product Backlog?
Esto puede parecer una tarea fácil, pero la verdad no lo es. Lo primero que hay que saber, es que para ordenar el backlog debemos de tener en cuenta varios elementos, en nuestro caso hablaremos de los siguientes, pero podrían ser otros, depende del contexto y del producto:
- Tamaño, esfuerzo o coste
- Valor
- Riesgo
- Y dependencias
Hay muchos otros sistemas de ordenación o priorización de Backlog que utilizan otros elementos. En este ejemplo utilizaremos el coste, valor o valor de negocio y el riesgo, de tal manera que podemos crear una ecuación para obtener un ranking que permitirá ordenar el backlog (PBIs) fácilmente:
Orden = (valor + riesgo) / coste
5 Técnicas para gestionar el Product Backlog
Tener un Product Backlog completamente refinado
Es un típico error en Scrum intentar tener todo el Backlog Refinado, con todos los requisitos del producto, como si se tratará de una gestión tradicional de proyectos, alcance cerrado, en fecha y en coste. No obstante esto no va de eso, sino, esto va de la entrega de valor a través de la creación de productos, es algo que no termina, siempre mientras el producto siga vivo y aportando valor a los usuarios. Por lo tanto es un poco absurdo intentar crear un Backlog completo para algo que no termina. ¿Y cómo lo hacemos entonces?
Lo importante aquí es empezar a crear un Backlog con las ideas que más valor aportan, de manera iterativa e incremental, luego iremos inspeccionando y adaptando, según las necesidades de los usuarios, mercado, tecnología, etc.
El Product Owner es el único que gestiona el Backlog
Es un malentendido común sobre que el PO es la única persona quien debe de crear Items en el Backlog, ordenarlo etc. De hecho muchos POs optan por hacerlo ellos mismos, ojo, no digo que esto sea malo, sino, que el Product Owner puede involucrar a los desarrolladores de producto más permitiendoles que le ayuden con ciertas actividades de la gestión del Backlog. Imaginemos la situación siguiente, el producto tiene que hacer lo siguiente:
- Crear las historias
- Diseños funcionales
- Criterios de aceptación
- Roadmap
- Etc.
Al final el PO se convierte en un escriba y poco más. Pero si el PO es un emprendedor, debería de estar enfocado más en el mercado, usuarios, novedades, roadmap, visión, estrategia, etc.
Tener todo el Backlog estimado
Como comentábamos antes, si hacemos esto, estamos asumiendo mucho riesgo, ya que estamos suponiendo que no va a cambiar nada en el producto y quizás estamos mal invirtiendo el tiempo del equipo. Ojo, estoy hablando de refinamientos completos de todo el Backlog por adelantado para tener muy detallado todo el Backlog.
Product Backlog Item muy detallados
Tener unos Ítems del Backlog (PBIs) con una lista muy completa y una gran lista de criterios de aceptación. Ni blanco ni negro, busquemos un equilibrio, cada PBI podría tener entre 3 a 5 criterios de aceptación y si hay más, podemos dividir los PBIs y así tenemos mas items, de tal modo podemos reducir los riesgos y acelerar el aprendizaje.
No todo lo que hay en el Backlog son Historias de usuario
Es otro de los antipatrones de Scrum, donde las personas piensan que todo lo que hay en el Backlog debe de ser en formato de historia.
Cómo <Rol/…>
Quiero <funcionalidad/…>
Para qué <valor de negocio/…>
El formato es una plantilla que se puede utilizar para describir algunos PBIs, pero podemos encontrar otros elementos que son mejoras técnicas, pruebas, requisitos no funcionales, bugs, etc.
¿Qué pasa con los Ítems que no terminan en un Sprint?
Primero hay que tener en cuenta que no todo lo que planificamos vamos a ser capaces de hacerlo en un Sprint, esto suele pasar y mucho en el caso de los equipos nuevos. Y puede ser por muchos motivos:
- Hemos planificado más de lo que podemos hacer
- El trabajo resultó más complicado de lo que pensábamos
- Debido a algunas circunstancias durante del Sprint
- Etc.
Si esto sucede el equipo puede eliminar del Sprint los PBIs menos orden/prioridad/valor para poder poner foco en los PBIs de más valor para el Sprint Goal. ¿Y qué hacemos con los PBIs eliminados del Sprint?
Si el equipo ha tenido que eliminar PBIs, el equipo debe devolver los Items del Backlog. Y si no consiguen terminar algún ítem al final del Sprint, igual, esto va al Backlog. ¿Y por qué debe de ir al Backlog y no al siguiente Sprint?
La respuesta es fácil: es posible que las necesidades del negocio hayan cambiado, criticidad, riesgo de otros elementos, etc. Esto le permite al Product Owner re-ordenar el Backlog y quizas enviar estos elementos al final del backlog y poner otros más arriba.
Si te ha gustado o aportado este artículo, compártelo y valorarlo.
Gracias y un saludo
