El término «backlog» alcanzó una gran popularidad de la mano de Scrum llegando incluso a trascenderlo. Muchos utilizamos en la actualidad el término «backlog» aún sin estar trabajando necesariamente con Scrum. En este sentido he visto enfoques de uso de backlog muy diversos entre los que me parece destacan 2.

En un extremo está la visión más cercana a Scrum donde el backlog está centrado en el producto, sus ítems están expresados en términos negocio, típicamente con forma de user stories y épicas.

En el otro extremo tenemos un backlog que representa el trabajo por hacer y si bien todos sus ítems tienen alguna relación con el producto/servicio que estamos construyendo, esa relación no siempre es tan directa o evidente. El backlog es en este caso una herramienta de gestión del trabajo y en parte por ello sus ítems no siempre toman la forma de user stories, sino que muchas veces son tareas.

He visto equipos trabajando con uno u otro enfoque de backlog y también he visto equipos trabajando con ambos tipos de backlog en simultáneo. Y obviamente también he visto equipos trabajando con enfoques distintos a estos dos.

En lo personal, y desde mi posición de miembro del equipo de ingeniería, tiendo a inclinarme por el segundo enfoque, es fundamental para mi tener en bien en claro y visible todo el trabajo por delante. Me ha pasado de trabajar con equipos «novatos» en términos de gestión que intentan trabajar con un backlog puramente de producto y que pierden de vista tareas indispensables para la entrega de valor como ser la gestión de ambientes, configuración y demás tareas relacionadas a la puesta en producción.