Gestión de proyectos

Qué es un backlog (y qué no es)

En una línea: un backlog es la cola de trabajo pendiente de un equipo, ordenada por prioridad: lo que falta hacer, con lo más importante arriba. No es una caja de ideas ni un archivo de “para algún día”; es una lista viva que se poda. Si tu backlog crece sin límite y nadie lo revisa, dejó de ser un backlog.
8 min de lectura

Qué es un backlog

Un backlog (en español, “lista de pendientes” o “trabajo en cola”) es el conjunto de trabajos que un equipo sabe que tiene que hacer y todavía no hace, ordenado del más al menos importante. La palabra viene de Scrum —donde el product backlog es el inventario priorizado de lo que el producto necesita— pero el concepto sirve para cualquier equipo: agencias, contenido, operaciones.

Las dos propiedades que hacen que una lista de pendientes sea un backlog:

  • Está ordenado por prioridad, no por fecha de llegada. Lo de arriba es lo próximo que entra; lo de abajo espera su turno. No hay tres cosas “urgentes” empatadas.
  • Se revisa y se poda. Cada semana o cada sprint, alguien quita lo que ya no importa, reordena y afina lo que está por entrar. Un backlog que solo crece no es una cola: es un cementerio con orden alfabético.

El complemento del backlog es el tablero: el backlog dice qué va a entrar; el tablero kanban dice qué está pasando ahora. Son capas distintas del mismo sistema.

Los 3 backlogs que verás en la práctica

“Backlog” no es una sola cosa. Según el marco, la palabra nombra colas distintas:

BacklogQué contieneQuién lo ordena
Product backlogTodo lo que el producto podría necesitar: funcionalidades, mejoras, deudas. Horizonte de meses.El product owner (o quien decida producto en tu equipo).
Sprint backlogEl subconjunto comprometido para un sprint de 1–4 semanas. No crece durante el sprint.El equipo, en el sprint planning (cómo se hace ese compromiso en Sprint planning que se cumple).
Backlog del tablero (kanban)La columna “Por hacer”: las tarjetas listas para entrar, ordenadas. Sin sprints: entra cuando el WIP lo permite.El equipo, en la revisión semanal del tablero.

En equipos pequeños, el product backlog y el backlog del tablero suelen ser el mismo: la columna “Por hacer” con un tope de 10–15 tarjetas y el resto en una lista aparte. Está bien. Lo que no está bien es que la columna tenga 90 tarjetas “por si acaso”.

Qué entra en un backlog (y qué no)

El filtro tiene una pregunta: ¿esto va a entrar al trabajo de las próximas 4–6 semanas si nada cambia?

  • Entra: trabajo ya acordado con cliente o con producto, historias suficientemente concretas para estimar, deudas técnicas o de proceso ya reconocidas, mejoras con dueño que las pide.
  • No entra (todavía): ideas sin discutir, “estarías bueno hacer X”, bugs sin reproducir, deseos de stakeholders que nadie priorizó. Eso vive en una lista de ideas separada —un notebook, un tablero de “estanqueidad”, lo que sea— y sube al backlog solo cuando alguien responde la pregunta de arriba.

Y una cosa que nunca debe estar en un backlog: trabajo comprometido y en curso. Eso es tarjetas del tablero, no cola. La diferencia entre lista de tareas personal y backlog de equipo (que incluye plazos, dependencias y alcance) está en Lista de tareas vs gestión de proyectos.

Cómo se mantiene: el refinement en 30 minutos

En Scrum la ceremonia se llama refinement (o grooming) y no necesita más de 30 minutos semanales en un equipo pequeño. Tres actividades, en este orden:

  1. Podar. Recorrer de abajo hacia arriba y eliminar sin drama lo que ya no se va a hacer. Si te da pena, muévelo a la lista de ideas; no lo dejes en la cola.
  2. Afinar lo que está por entrar. Los primeros 5–10 items: partir lo grande en piezas de días (el formato para cortar trabajo está en Historias de usuario), aclarar criterios de “hecho”, adjuntar lo que falta para poder empezar.
  3. Reordenar. Subir lo que el cliente o el negocio movió; bajar lo que sonó urgente y dejó de serlo.

El objetivo no es un backlog “completo”: es un backlog confiable en su parte superior. Nadie sabe qué hay en la posición 47 y nadie lo necesita; lo que sí necesita el equipo es que lo de arriba esté listo cuando el WIP abra espacio.

Los 4 síntomas del backlog enfermo

  • Crece más rápido de lo que sale trabajo. La cola es un inventario; inventario que no rota es una promesa muerta. Regla: si un item lleva 2 meses sin moverse, se elimina o se reescribe.
  • Nadie sabe quién ordena. Sin un dueño de prioridades, todo es “importante” y el equipo termina eligiendo por el orden que resulta cómodo.
  • Tiene items de 3 semanas. “Rediseñar toda la web” no es un item de backlog; es un proyecto con varias historias dentro.
  • Se usa como archivo. Si los items se guardan “para no perder la idea”, esa es la función de una lista de ideas, no de una cola de trabajo.

Un backlog sano es corto donde importa: 10–20 items en la zona activa, orden real y un dueño. El resto del sistema —cómo entra el trabajo al tablero y a qué ritmo sale— es flujo kanban, y está en Tablero kanban: qué es y cómo usarlo.

Si gestionas el backlog en una herramienta y quieres que viva en tu carpeta —JSON local, sin cuenta ni asientos, con tablero y procesos— Hito está hecho para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — backlog, tablero kanban y procesos en tu propio equipo. Sin nube, sin cuenta.

Preguntas frecuentes

¿Qué es un backlog?
Es la cola de trabajo pendiente de un equipo, ordenada por prioridad: lo que se sabe que hay que hacer y todavía no se hace, con lo más importante arriba. Se revisa y se poda de forma continua; si una lista de pendientes crece sin límite y nadie la ordena, es un archivo, no un backlog.
¿Cuál es la diferencia entre product backlog y sprint backlog?
El product backlog contiene todo lo que el producto podría necesitar a meses vista, ordenado por valor. El sprint backlog es solo el subconjunto que el equipo se compromete a completar en un sprint de 1–4 semanas, y no crece durante el sprint. Uno es el inventario completo; el otro, el compromiso de la semana.
¿Un backlog es lo mismo que una lista de tareas?
No exactamente. Una lista de tareas es captura: lo que se te ocurre, sin orden comprometido. Un backlog está priorizado por alguien con autoridad, se poda y alimenta el trabajo entrante de un equipo. La diferencia práctica entre lista personal y gestión de proyectos (dependencias, alcance, varios dueños) está en Lista de tareas vs gestión de proyectos.
¿Quién mantiene el backlog?
En Scrum, el product owner ordena y el equipo afina en las sesiones de refinement. En un equipo pequeño sin roles formales: una sola persona dueña de prioridades (el líder, el fundador, el PM) y el equipo completo en una revisión semanal de 30 minutos. Lo que no funciona es el backlog de todos: sin dueño, no hay prioridad.
¿Cuánto debe medir un backlog?
Su zona activa: 10–20 items listos y ordenados; el resto puede ser una lista larga y difusa sin problema. Lo que importa es que la parte superior sea confiable: los primeros items tienen que estar listos para entrar al tablero cuando el WIP abra espacio. Si hay 200 items, podar es lo primero.

Equipo Hito

Producto · Escribimos sobre gestión de proyectos local-first desde la práctica de construir Hito.

Empieza

¿Listo para tener el control de tus datos y proyectos?