Una Guía al Backlog del Producto

Es un artefacto de toma de decisiones que te ayuda a estimar, refinar y priorizar todo lo que podrías querer completar en el futuro.

Ayuda a garantizar que el equipo esté trabajando en la funciones más importantes y valiosas, corrigiendo los errores más importantes o realizando otro trabajo importante crítico para el desarrollo de productos.

El backlog, por lo tanto, es tremendamente útil en situaciones en las que no puedes hacer todo lo que se te pide (por lo tanto, la mayoría de las situaciones), o en contextos en los que incluso una pequeña cantidad de planificación ayudará mucho (por lo tanto, en la mayoría de los contextos).

Muchos piensan en este backlog como una lista de tareas pendientes y lo definen exactamente de esta manera, como una lista de cosas que debes hacer para entregar tu producto al mercado.

En verdad, no es necesariamente una lista de tareas pendientes. Piensa en ello como una lista de deseos.

¿Por qué?

Cuando pensamos en el backlog como una lista de deseos, invitamos a la flexibilidad y al cambio. Al hacerlo, permitimos una verdadera agilidad y le damos a la organización un poder que es necesario para ganar en el mercado actual: el poder de cambiar de opinión.

En este contexto, el propósito del backlog se puede reducir a tres objetivos simples:

• Desarrollar un terreno común para alinear a los interesados y los equipos, de modo que los equipos implementen las historias de usuario más valiosas.
• Brindar flexibilidad para adaptarse a nuevas necesidades y realidades.
• Mejorar la precisión de los pronósticos de lanzamiento de productos mediante la creación de un denominador común entre muchos equipos que colaboran en un producto.

Este backlog a menudo se alimenta de una hoja de ruta estratégica, luego se divide en temas, épicas, sprints e historias de usuarios. La mayoría incluye elementos que se completarían en el próximo trimestre o año fiscal.

Quizás te estés preguntando, ¿cómo debería lucir este artefacto de toma de decisiones?

Honestamente, dar un ejemplo útil es difícil. Esto se debe a que un backlog bien construido se parece a lo que sea necesario para ayudar a los equipos a crear el producto más valioso en el tiempo disponible.

¡Hay poco para copiar y pegar en esa definición!

La razón es que la forma debe estar informada por el producto, así como por los procesos y necesidades del equipo que lo crea y se compromete con él.

En su forma más básica, un backlog es para un equipo y se alinea en torno a los objetivos. Esos objetivos se desglosan en características valiosas e historias de usuarios, que a su vez se priorizan, estiman, refinan y detallan de manera adecuada.

A continuación, se muestra un ejemplo del backlog para un juego de redes sociales. Está organizado por temas, funciones e historias de usuarios.

Imagen backlog juego redes sociales

En resumen, el backlog del sprint es el plan a corto plazo para el sprint del equipo. El backlog del producto es el plan a largo plazo del producto, donde la visión de desglosa en elementos concreto que se pueden entregar y que hacen que el producto sea más valioso. Muchos piensan en el backlog del sprint como un subconjunto del producto. Idealmente, esto es cierto; el backlog del sprint consta únicamente de elementos del backlog del producto. En la práctica, sin embargo, un backlog del sprint incluirá otros trabajos con los que el equipo se ha comprometido.

El backlog del producto es un contenedor para el trabajo que crees que harás en el futuro para mantener tu producto competitivo. Es la salida del Product Owner en colaboración con los interesados (clientes, equipo, analistas). Cambiará con frecuencia, y se agregarán o eliminarán elementos de forma regular. En general, será más grande que el backlog del sprint. También tendrá elementos con una mezcla de granularidad; con menos elementos desglosados por debajo del nivel de historia de usuario. Es supervisado por el Product Owner.

El backlog del sprint es un contenedor para el trabajo que el equipo se compromete a realizar ahora mismo como parte del sprint (generalmente un período de una a cuatro semanas). Es el resultado de una reunión de planificación del sprint a la que asistió el equipo. El backlog del sprint, idealmente, no cambia en absoluto durante la duración del sprint. Consiste en historias de usuarios que el equipo se ha comprometido a entregar dentro del período de tiempo del próximo sprint. Pero también puede incluir errores, trabajo de refactorización, etc. Por lo general, es más granular y se divide en tareas, centrándose en la implementación técnica de una historia de usuario. Es competencia del Scrum Master y del equipo.

Cuatro categorías principales de elementos (denominados elementos del backlog del producto) encajan en el backlog del producto. Dos son muy visibles para los clientes: características y errores. Los otros dos, la deuda técnica y la investigación, son invisibles para los clientes, pero no pueden ignorarse.

En una organización ágil, los elementos del backlog del producto se escriben normalmente como historias de usuario, aunque no siempre es necesario. También pueden redactarse como documentos de requisitos tradicionales o de otras formas.

Cuando se escriben como historias de usuario, los elementos del backlog del producto a menudo adoptan la siguiente forma:

Las solicitudes de nuevas funciones se originan en una multitud de fuentes. Estos incluyen usuarios finales, ventas, soporte, gestión de productos, etc. Las nuevas funciones pueden ser las más difíciles de priorizar a medida que intentas equilibrar las necesidades en competencia de:

• Mantener satisfechos a los clientes existentes.
• Satisfacer oportunidades de ventas a corto plazo.
• Trabajar una visión a largo plazo de tu producto.

El Product Owner debe monitorear estas fuentes de manera rutinaria y resolver cualquier solicitud conflictiva. Hacerlo ayudará a asegurarse de que el backlog contenga nuevas funciones que atraigan nuevos clientes y generen lealtad con los existentes.

La deuda técnica incluye el trabajo que debe realizarse para que el producto se mantenga actualizado y se pueda mantener. Los ejemplos para abordar la deuda técnica incluyen la actualización a las últimas bibliotecas de terceros, realizar cambios en la arquitectura para admitir una mejor escalabilidad o refactorizar el código fuente para evitar problemas de mantenimiento en el futuro. Cuando aumenta la deuda técnica, ya sea de forma deliberada o sin saberlo, puedes arriesgarte a retrasar los lanzamientos de productos.

La deuda técnica suele ser el resultado de cambios relacionados con:

• Dirección y alcance.
• Expectativas de rendimiento y escalabilidad.
• Tecnología o mejores prácticas.

Estos tipos se denominan a menudo “deuda técnica” debido a su similitud con la deuda financiera; tendrás que pagar intereses por ellos, pero en forma de un ciclo de vida de desarrollo más largo. Estas tareas deben agregarse a la acumulación y luego priorizarse junto con las características y los defectos, para que puedan incluirse en el ciclo de planificación.

Los errores y efectos son problemas descubiertos por los usuarios finales que escaparon al control de calidad durante el desarrollo. En un proceso de cascada, las pruebas suelen ser el último paso del ciclo de vida del desarrollo. Es bastante común publicar una versión en vivo con una gran colección de defectos menores (y a veces moderados). Los errores tienden a agruparse y acumularse con el tiempo si no se resuelven. A veces se administran dentro de un rastreador de problemas, pero también se pueden incluir como parte del trabajo pendiente.

La investigación es otro elemento que el usuario final no reconocerá como una característica, pero puede incluirse en un trabajo pendiente. La investigación es fundamental cuando se sabe muy poco sobre cómo implementar una nueva función o concepto, o si deseas probar algo nuevo. De cualquier manera, las circunstancias requieren que dediques tiempo para ampliar la comprensión del equipo. El resultado de estas historias de usuario, comúnmente llamadas “picos”, no es código de trabajo, sino conocimiento.

La planificación y organización adecuadas son parte integral de tu éxito. Ahí es donde los backlogs brindan orientación. Cuando se crea y gestiona correctamente, el backlog se convierte en una herramienta que ayuda a los equipos a navegar por los cambios constantes, alcanzar la máxima productividad y ofrecer el máximo valor tanto a la empresa como al cliente.