El Product Backlog, el Product Ganttklog y otros seres y estares

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.