¿Qué es el Backlog?

Si ya estás familiarizado con las metodologías y frameworks ágiles seguro que te sonará el término Backlog. En ese caso, espero contribuir a refrescar tu memoria y aclarar conceptos. Si no es así, este post te ayudará a entender su significado.

¿Qué es el Backlog?

La palabra inglesa Backlog significa “acumulación de algo, especialmente trabajo incompleto o cosas de las que debemos ocuparnos”. Es decir, una pila o montón de trabajo.

Si buscas por Internet te darás cuenta de que el término se asocia normalmente al uso de metodologías de trabajo ágiles para el desarrollo de software y en particular al framework Scrum, que es el más ampliamente utilizado. En este contexto, la palabra Backlog aparece siempre unida a Producto. ¿Por qué? Muy sencillo: el “Product backlog” es el artefacto que sirve como contenedor de todo el trabajo que hay que hacer para desarrollar un producto.

Una definición sencilla es la siguiente:

“El Product Backlog es una lista de todo el trabajo pendiente, ordenado por prioridad”.

El Product Backlog no es una simple lista de tareas

Así es, el Backlog de Producto en Scrum no es un mero listado de tareas.

El Product Backlog y los elementos que lo integran, que denominaremos entradas o ítems, tienen una serie de características:

• los ítems del Backlog deben agregar siempre valor para el cliente
• los ítems del Backlog deben estar priorizados, esto es, ordenados según criterios de prioridad (valor de la funcionalidad para el cliente, tamaño, dificultad, etc.). Cuanto mayor sea su prioridad, más arriba deben estar en la pila.
• el nivel de detalle de cada ítem del Backlog depende de su posición dentro de la pila. Los de más arriba estarán más detallados (refinados), para poder abordarse antes.
• Los de más abajo contendrán menor detalle, pues se abordarán más tarde y es posible que antes se modifiquen o incluso se descarten.
• todos los ítems deben estimarse
• el Backlog es un documento vivo, sujeto a cambios, en el que puede entrar o del que puede salir trabajo.
• el Backlog no debe contener elementos de acción ni tareas de bajo nivel

La mayor parte de estos puntos, se corresponden con los aspectos fundamentales que identifica el acrónimo DEEP a la hora de elaborar un Product Backlog: Detailed appropriately, Emerging, Estimated y Prioritized.

Detallemos a continuación estas características.

Incluir sólo entradas que aporten valor

Todos y cada uno de los ítems del Backlog deben agregar valor para el cliente. Todo trabajo que no aporte valor debe ser excluido del Backlog, de lo contrario será un desperdicio de tiempo, un esfuerzo inútil y baldío.

En el Backlog se pueden incluir entradas para explorar necesidades del cliente, analizar opciones técnicas, describir requisitos funcionales y no funcionales, el trabajo necesario para lanzar el producto y otros ítems de trabajo tales como la corrección de errores (bugs) o la configuración del entorno. Se nos pueden presentar dudas con tareas que no aporten un valor directo a una determinada funcionalidad. Sin embargo, agregarán valor si van a contribuir a aumentar la calidad del código o reducir los errores e incidencias a medio y largo plazo.

Priorización

Todas las entradas del Backlog deben estar ordenadas en base a su prioridad. Los ítems más prioritarios están en la parte de arriba y los menos prioritarios en la parte de abajo. La priorización es responsabilidad del Product Owner, aunque puede contar con la ayuda del resto del equipo Scrum. Algunos de los factores más habituales que se tienen en cuenta para priorizar los ítems son: valor que aporta al cliente/negocio, tamaño, coste, dificultad o riesgo. Gracias al Product Backlog, la pila de trabajo priorizado, el Product Owner puede decidir qué trabajo se debe hacer a continuación.

Diferente nivel de detalle

Los ítems del Backlog tienen una granularidad diferente. Mientras que los elementos a implementar durante los próximos Sprints deben estar definidos con mayor detalle, el resto pueden estar definidos de manera más general. El motivo es que no tiene sentido invertir tiempo y esfuerzo en la descripción detallada de los requisitos de una historia de usuario o tarea hasta que comience su implementación. Con bastante probabilidad, cuando vaya a abordarse dicho trabajo, dichos requisitos pueden haber cambiado sustancialmente.

Todas las entradas son estimadas

Todas las entradas dentro del Product Backlog deben estimarse de acuerdo con la definición acordada (por ejemplo, puntos de historia). Esta estimación se puede utilizar para priorizar las entradas del Backlog y para planear las entregas (releases).

Documento vivo

El Product Backlog en Scrum se modifica durante todo el proyecto. Si es necesario se pueden agregar nuevas funcionalidades y requisitos. Las entradas existentes pueden modificarse, definirse con más detalle o incluso eliminarse. Las funcionalidades y requisitos (alcance) no están completamente definidos desde el principio. Por el contrario, el Backlog se desarrolla de forma iterativa, junto con el software resultante. Esta forma de trabajar es completamente diferente al desarrollo tradicional en cascada, donde el alcance y la planificación están completamente definidos y detallados desde el inicio, pero en cambio, permite maximizar la entrega de valor al cliente de forma iterativa y minimiza el esfuerzo de desarrollo. Esto permite detectar errores en su etapa más temprana y por tanto minimizar los riesgos.

No hay tareas de bajo nivel

El Product Backlog no contendrá información detallada de las funcionalidades o historias de usuario. El desglose y la distribución de dichos ítems en tareas de mayor detalle que incorporen los requisitos con mayor grado de refinamiento es responsabilidad del Equipo Scrum y su lugar el Sprint Backlog

Más sobre el Backlog en Scrum

En este otro post hablamos sobre los dos tipos de Backlog que distingue Scrum (Product Backlog y Sprint Backlog), así como para quién (roles) es importante cada uno de ellos.

Please follow and like us: