El más conocido como Product Backlog, también conocido por algunos como “Pila de Producto”, o mejor traducido por el amigo Lucho Salazar, aunque sea su término menos popular, en la guía oficial de Scrum como “Lista de Producto” es, como muchos otros “elementos” de Scrum, algo bastante mal interpretado y castigado. Hasta ahí estamos dentro de lo normal, por desgracia, pero sería sensato decir que concretamente el caso de las malas interpretaciones del Product Backlog es algo un tanto más especial, por la transcendencia e importancia que este tiene.
Según dicen algunos, y yo no estoy en desacuerdo con ellos, para lo importante que es el Product Backlog, la definición que da de él la Guía de Scrum quizá debiera cuidarse más y detallarse más, dadas las malas interpretaciones a las que el término se da. Aunque eso de evitar malas interpretaciones roza lo imposible, pero si intentar reducirlas.
Extraído literalmente de la citada Guía de Scrum en castellano, el Product Backlog…
“…una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.”
“…Una Lista de Producto nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio.”
“…enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras. Los elementos de la Lista de Producto tienen como atributos la descripción, la ordenación, la estimación y el valor…”
Los anteriores son solo un extracto, del que no sólo hay de vez en cuando polémica o debate por el uso de palabras como “estimación” o “requisitos”. También hay mucha idea de mutar todo ello hacia… lo de toda la vida, pero con otro nombre.
Así que, con el sano objetivo de prevenirte en esas malas interpretaciones, te he preparado una breve enumeración de las que yo con más frecuencia me encuentro, a ver qué te parece y a ver si te suena alguna…
El Product Backlog que es un Proyecto
El problema de los Backlog, muchas veces, es pensar que hay que hacerlo todo, y que tiene que estar todo, entrar así en la rutina de hacer lo siguiente y lo siguiente y lo siguiente. Valorar y poner precio a un Backlog… tener un proyecto en vez de producto. Tener un Product Backlog con todos y cada uno de los ítems cerrados, que se piensan necesarios para el producto que se va a construir, está más cercano a tener una especificación de requisitos de toda la vida y/o de trabajar más en modo proyecto que en modo ágil.
Esto puede hacer olvidar la re-ordenación del Product Backlog para intentar constantemente maximizar el valor. El papel del Product Owner se desvanece, el cual debe día sí y día también buscar un Backlog que de más valor, aprovechando la infrormación que le dan los productos potencialmente entregables de fin de sprint.
El Product Ganttlock
Es una derivación peor del caso anterior, en el que las historias o items del Backlog cerrado, se ponen en un diagrama Ganttt… y hasta hay quien le mete dependencias. Si te quedó claro el punto anterior… creo que no hace falta que te explique mucho la aberración de este segundo caso.
El Product Backlog Estimado
Los peligros de la estimación están ampliamente tratados en la corriente #noestimates, te hablé de ello en ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado y enUn proyecto ágil se guía por valor no por estimación (más sobre #noEstimates). Todo ello aquí aplica de igual manera. Si todo el Product Backlog está estimado, es casi inevitable que la gestión se centre en exprimir las estimaciones, en evitar el cambio de items por otros de más valor. Y en la toma de decisiones se centre en cuánto hacer y qué aplazar.
El Product Backlog Priorizado
Ojo, definición falsa pero convincente de Product Backlog: ordenado por prioridad (Priorizando el product backlog), ojo, pero por prioridad dada por el valor. El Product Backlog tiene que centrarse en ofrecer el mayor valor, no elementos de «más alta prioridad», cuidado con el truco.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Muchas gracias por el post, me sirvió mucho. Me he acabo de dar cuenta que en mi empresa estamos usando un Ganttlock, por culpa de las presiones de los gerentes que quieren saber «¿cuándo termina el proyecto?».
PS: Cuidado con la ortografía… jajajaja
Es una paradoja ser ágil, cuando a fin de cuentas escuchas: “Para este sprint lo que tiene que subir a pro es A, B y C”. Es complicado cambiar eso, pero es necesario, porque si no, lo que tenemos es un Cascade-Agile o Agile-Cascade.
Buen post Javier, aunque me cuesta mucho deshacerme de la idea de no estimar. Esta claro que debemos centrarnos en el valor por encima de todo, pero a la hora de decidir qué hacemos en el próximo Sprint es también necesario contar con información sobre qué esfuerzo implica cada historia de usuario, al menos a alto nivel. Si tenemos historia A y B, la historia A aporta valor 100 y esfuerzo 100 y la historia B aporta valor 90 pero esfuerzo 10, quizás es interesante primero hacer B antes que A. Entiendo que si hablamos de historias que van a entrar en un Sprint son lo suficientemente pequeñas para poder comparar por valor, pero a la hora de ordenar un backlog de producto, ¿no te fijas en serio en lo que costaría implementar cada historia grande o épica?
Ciertamente, el #noestimates tampoco se cierra a que se estime, lo que viene a resaltar es que la estimación debería estar en un papel secundario no tan determinante y bloqueante como ahora.
Ahora, en tu ejemplo hacer la B antes que la A por coste… tiene mala pinta, estás premiando «cantidad» entregada en vez de valor…
No me malinterpretes Javier, precisamente lo que estoy planteando es de ver la big picture, y no quedarme solo con el valor de negocio a secas. Llevándolo al absurdo, tener una historia A de valor 100 y esfuerzo 2 años, y otra historia B de valor 90 que se puede hacer en 2 semanas, no me dirás que haces primero la A 😉
Además del valor hay otros indicadores como el Cost of Delay que se deben tener en cuenta.
Eso sí, te compro que mirar cantidad y fechas cerradas es igual de absurdo y sin embargo es lo que más se mira en las organizaciones a día de hoy.