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.
Excelente artículo. Gracias
Muchas gracias Jose María.
Lo escribí con gran ilusión y ganas de ayudar a que este “artefacto” se entienda y use correctamente, tanto por los equipos de desarrollo como sobre todo por parte de los Product Owner.
gracias, no lo conocia y lo debo utilizar.
Gracias Isabel. Te animo a que lo uséis, es un elemento esencial en el trabajo de los equipos ágiles para el desarrollo de cualquier producto o proyecto.
Muy clara la explicación.
Gracias por aclarar las 6 etapas a considerar en el Product Backlog.
Nota: no encontré el articulo de su autoría sobre el ”Sprint Backlog”
Gracias Carlos.
El otro artículo al que hago referencia, el relativo al Product Backlog y Sprint Backlog, está al final del artículo, bajo el epígrafe “Más sobre el Backlog en Scrum“.
Si colocas el cursor sobre el texto entre paréntesis “(Product Backlog y Sprint Backlog)” verás que ahí tienes el hiperenlace.
Hola, Gracias por el articulo, quería consultar un tema de nomenclatura, si uno toma un item del Backlog para desarrollar y está en proceso o terminado ¿sigue siendo parte del Backlog o el Backlog es solo la pila de temas pendientes??
Gracias por la aclaración
Estimado Gerardo. El Backlog es solamente la pila de trabajo pendiente para el Producto en desarrollo, aunque es un artefacto vivo sujeto a cambios en cualquier momento.
Una vez un item del Backlog se aborda en un Sprint, pasa del “Product Backlog” al “Sprint Backlog”, se trabaja sobre él y lo normal será finalizarlo.
Al terminar el sprint, si el ítem desarrollado es aceptado por el Product Owner conforme a los Criterios de Aceptación definidos para el mismo, logicamente ya no formará parte del “trabajo pendiente”.
Podría suceder sin embargo, que no fuese aceptado por el PO. En ese caso pueden darse varios escenarios: el más habitual, meterlo en el “Sprint Backlog” del siguiente Sprint para terminarlo, o bien, aunque menos probable, devolverlo al “Product Backlog” si es que hay algún bloqueo o ha dejado de ser prioritario en ese momento, o incluso descartarlo definitivamente.
Esperamos haberte sido de ayuda.
Por favor indica que herramientas utilizas para gestionar el backlog macro hasta el nivel de las historias.
Gracias
En nuestro entorno laboral y en muchas compañías con las que trabajamos se utiliza la herramienta JIRA, del fabricante Atlassian.
No es la única, aunque sí una de las más extendidas. Hay otras grandes herramientas como por ejemplo VersionOne, CA Agile Solutions (antes RALLY), TargetProcess, etc.
JIRA incorporó ya hace tiempo mecanismos para la gestión de proyectos ágiles, y permite disponer de un Backlog así como crear tableros Scrum y Kanban, para adaptarse a diferentes enfoques de trabajo.
muy interesante