Supongo que esto ya lo sabe todo el mundo, pero, por empezar como se debe, conviene recordar que el Product Backlog en Scrum es una lista de items priorizados. Una lista ordenada con todo aquello que debe añadirse al producto. Y uso la palabra item como algo general, y conscientemente ambiguo, porque aunque lo típico es hacer uso de “historias de usuario” ello no impide que en el Product backlog pueda haber otras “cosas”.
Para más información de lo hasta aquí hablado, yo me leería El Product Backlog, el Product Ganttklog y otros seres y estares y Priorizando el product backlog.
Y ahora vamos con lo que hoy quería escribir…
¿Tamaño del Product Backlog? ¿Cuántos items?
Como es obvio, no hay una regla, no hay una norma, sobre el número de items que debe tener un product backlog, sería absurdo que la hubiera, depende de muchos factores. Lo que sí podemos hacer es recoger un conjunto de buenas prácticas que te orienten sobre ello y verás que todas aellas van a ir en la línea de reducir “su peso”, su tamaño.
Como primera idea, ya que estamos en un ciclo de vida “iterativo e incremental”, orientado al cambio, no es necesario tener todos los items para empezar a trabajar. Por lo general, se puede comenzar con un primer subconjunto (algunas referencias sobre esto, aquí), más que suficiente para un primer, o unos cuantos, sprint.
El Product Backlog crece y cambia a medida que se aprende más sobre el producto y sus clientes, por ello…
Un Product Backlog nunca está completo
En los modelos de trabajo más tradicionales, no se comenzaba hasta que estaba cerrada por completo la llamada especificación de requisitos, que, además, se buscaba que una vez cerrada no se moviera. A diferencia de ello, por definición, un Product Backlog nunca está terminado.
Pasarse metiendo items en el Product Backlog, en los que previsiblemente se trabajará dentro de muchos Sprints, lleva al desperdicio de que con el tiempo no tengan sentido, cambien, se eliminen.
El efecto trastero
Además, pasarse rellenando de items el Product Backlog puede llevar al típico “efecto trastero”, aquel en el que uno guarda cosas, por no tirarlas, pasa el tiempo, hasta se olvida de ellas, y hasta incluso vuelve a comprar esas cosas porque ya no recordaba que las tenía guardadas.
Si algo lleva en el Product Backlog demasiado tiempo… elimínalo, si realmente era importante… ya volverá a aparecer.
Product Backlog como inventario
Y si solo (repito, solo) lo ves desde el punto de vista Lean (y no entro más aquí, porque entrar en Agile vs Lean, en este punto, tendría su profundidad), los items en el Product Backlog hacen de “inventario”, cosas que están ahí consumiendo y no generando beneficio y ello es… desperdicio
Muchos items a priorizar más tiempo lleva la priorización
Un Product Backlog está priorizado por valor. Al menos, un subconjunto, el de mayor prioridad, está priorizado. Intenta que el conjunto a priorizar sea mínimo.
Imagina 100 items en el Product Backlog, las posibles combinaciones, a la hora de priorizar uno tras otro, son más que el número de átomos en el universo.
Opciones…
Si necesitas tener visibilidad a largo plazo, guardar cosas probables, pero no quieres perder tiempo en entrar en detalles, recuerda, que tienes otras opciones, como hacer uso de “Temas” o “Epics”, las cuales, cuando les llegue el momento, serán detalladas en items de menor nivel.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023