El Product Backlog es un artefacto de Scrum vital para cambiar la manera en la que desarrollamos software. Su función no es recoger todo lo que vamos a hacer, sino todo aquello que “puede” que lleguemos a hacer. Su característica esencial es que debe estar ordenado, es decir, los elementos se sitúan en un orden vertical, en función de cómo realizaremos los diferentes elementos para incrementar nuestro producto. Analizamos las características de un Product Backlog y de cómo ordenarlo.
¿Qué es un Product Backlog?
La definición formal de la ScrumGuide es que el Product Backlog es una lista ordenada que contiene todo lo que sabemos que va a necesitar nuestro producto. Su responsable es el Product Owner quien es el encargado de su mantenimiento.
El Product Backlog se define como incompleto porque es un elemento vivo que se debe adaptar a medida que el Scrum Team descubre una mejor manera de construir su producto para generar valor. Un Product Backlog que no evoluciona es sintomático de que algo no va bien, de que seguimos con el paradigma de “entregar todo” por encima de adaptarnos para maximizar valor.
Los elementos que contiene el Product Backlog pueden ser de cualquier tipo: casos de uso, historias de usuario, features o experimentos. También puede contener los test para validar cuándo un item concreto está finalizado.
En la parte superior, se deben colocar los elementos candidatos a abordarse y, por tanto, estarán más detallados y claros que los del nivel inferior.
Maximizando valor
El objetivo de todo equipo Scrum es la maximización de valor. Esto significa que debemos conseguir que nuestro producto genere valor que, en términos normales, significa dinero, de manera directa o indirecta. Los elementos del Product Backlog no generan valor por sí mismos, sino que incrementan nuestro producto, que es el que produce el valor.
Por tanto, decidir qué elementos queremos construir son vitales, ya que modificarán nuestro producto. Podemos incluso crear valor negativo, lo que supone que incrementamos el producto y nuestro mercado lo rechaza.
Además, no es cuestión solo de crear elementos que aporten valor directo. A veces, tendremos que incluir elementos técnicos para evitar fallos futuros que afecten al valor de nuestro producto, o bien elementos relacionados con un tema legal. Un Product Owner debe tener, encima de la mesa, todas estas cuestiones claras para poder ordenar el Product Backlog.
¿Cómo ordenar el Product Backlog?
El Product Backlog es un elemento vivo que se puede ordenar de múltiples maneras. La regla general es que no hay regla. Como artefacto, debe ayudar al Product Owner a poner el trabajo en el orden que le ayude a maximizar el valor de su producto. Pero cuidado, no debemos caer en la trampa de ordenarlo por valor, puede que acabemos haciendo grandes items (con mucho coste) a pesar de que aporten mucho valor.
Por tanto, tiene sentido buscar el equilibrio entre valor y tamaño. Para mí, este puede ser el momento donde estimar tenga más sentido en Scrum, no para ser exactos o predecibles, sino para que el Product Owner pueda tomar decisiones: “si me decís que esto es difícil, y esto es sencillo y aporta algo menos de valor, vamos a centrarnos en lo segundo”.
Pero no todo debe ser valor y tamaño. Tenemos también que introducir el “valor futuro”. Por ejemplo, podemos invertir en tecnología que nos habilite un continuous delivery, automatizando el despliegue. Esto no nos aporta un valor directo a corto plazo, pero nos genera oportunidades futuras. Por tanto, tenemos que ser capaces de compatibilizar valor futuro con valor actual. En este concepto, debemos incluir la deuda técnica: aquellos aspectos que hemos evitado por algún motivo y que debemos acabar resolviendo. En Scrum, ya se planteó que, al menos, una mejora debía incluirse en cada Sprint. Si no incluimos mejoras técnicas, será difícil tener un producto sostenible a largo plazo.
Otro concepto que no se nos puede olvidar son los riesgos. Puede que tengamos items que no estén muy definidos, o que tengan dependencias de otros equipos o de agentes externos a la organización. Estos items son peligrosos incluidos en un Sprint, porque se asume el riesgo de que no podamos completarlos. Todo lo que no completemos pasará a ser deuda y, por tanto, no solo no generaremos valor, sino que generaremos más trabajo.
Y por último, tenemos que estudiar los posibles experimentos que queramos hacer en nuestro producto. Entendamos un experimento como un item técnico cuyo valor futuro es desconocido por lo que tenemos que hacer algún tipo de prueba o spike para estudiar su viabilidad. Puede convertirse en trabajo que no aporte valor o que sí, pero no lo sabemos a priori.
Conclusiones
Resumiendo todo lo que hemos estudiado, un Product Owner tiene que buscar un equilibro entre valor actual y futuro, mejoras técnicas, experimentos, riesgos, tamaños… ¡maximizando valor!
La conclusión es sencilla: que ordene como considere, no hay una regla definida. Cada producto y cada estrategia buscarán unos items u otros. Lo que garantiza que un Product Owner buscará hacer bien su trabajo es la rendición de cuentas en la organización sobre el impacto de su producto.
Y tú ¿cómo ordenas el Product Backlog?
