---

name: manage-backlog description: > Crear y mantener un backlog de producto o proyecto con elementos priorizados, criterios de aceptación y estimaciones. Cubre la escritura de historias de usuario, la priorización MoSCoW, el refinamiento del backlog, la división de elementos y el seguimiento de estados. Usar al iniciar un nuevo proyecto y convertir el alcance en elementos accionables, durante el refinamiento continuo antes de la planificación del sprint, al repriorizar después de comentarios de interesados o cambios de alcance, o al dividir elementos sobredimensionados en piezas implementables. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: intermediate language: multi tags: project-management, backlog, user-stories, prioritization, grooming, moscow locale: es source_locale: en source_commit: 6f65f316 fence_basis_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16

Gestionar un Backlog de Producto

Crear, priorizar y mantener un backlog de elementos de trabajo que sirva como única fuente de verdad sobre lo que debe hacerse, aplicable tanto a metodologías de proyecto ágiles como clásicas.

Cuándo Usar

• Al iniciar un nuevo proyecto y convertir el alcance en elementos accionables
• Refinamiento continuo del backlog antes de la planificación del sprint
• Al repriorizar el trabajo después de comentarios de interesados o cambios de alcance
• Al dividir elementos sobredimensionados en piezas implementables
• Al revisar y archivar elementos completados o cancelados

Entradas

• Requerido: Alcance del proyecto (del acta, EDT o información de interesados)
• Opcional: Archivo de backlog existente (BACKLOG.md) para actualizar
• Opcional: Preferencia de marco de priorización (MoSCoW, valor/esfuerzo, WSJF)
• Opcional: Escala de estimación (puntos de historia, tallas de camiseta, persona-días)
• Opcional: Retroalimentación de sprint o iteración que requiera actualizaciones del backlog

Procedimiento

Paso 1: Crear o Cargar la Estructura del Backlog

Si no existe ningún backlog, crear BACKLOG.md con columnas estándar. Si ya existe, leer y validar la estructura.

# Product Backlog: [Project Name]
## Last Updated: [YYYY-MM-DD]

### Summary
- **Total Items**: [N]
- **Ready for Sprint**: [N]
- **In Progress**: [N]
- **Done**: [N]
- **Cancelled**: [N]

### Backlog Items
| ID | Title | Type | Priority | Estimate | Status | Sprint |
|----|-------|------|----------|----------|--------|--------|
| B-001 | [Title] | Feature | Must | 5 | Ready | — |
| B-002 | [Title] | Bug | Should | 2 | Ready | — |
| B-003 | [Title] | Task | Could | 3 | New | — |

### Item Details

#### B-001: [Title]
- **Type**: Feature | Bug | Task | Spike | Tech Debt
- **Priority**: Must | Should | Could | Won't
- **Estimate**: [Points or size]
- **Status**: New | Ready | In Progress | Done | Cancelled
- **Acceptance Criteria**:
  - [ ] [Criterion 1]
  - [ ] [Criterion 2]
- **Notes**: [Context, links, dependencies]

#### B-002: [Title]
...

Esperado: BACKLOG.md existe con estructura válida y estadísticas de resumen.

En caso de fallo: Si el archivo está malformado, reestructurarlo preservando los datos de los elementos existentes.

Paso 2: Redactar o Refinar Elementos

Para cada nuevo elemento, redactarlo como una historia de usuario o requisito:

• Formato de historia de usuario: "Como [rol], quiero [capacidad] para que [beneficio]"
• Formato de requisito: "[Sistema/Componente] deberá [comportamiento] cuando [condición]"

Cada elemento debe tener:

• ID único (B-NNN, incremental)
• Título claro (forma verbal imperativa)
• Clasificación de tipo
• Al menos 2 criterios de aceptación (verificables, aprobación/rechazo binario)

Ejemplo:

#### B-005: Enable User Login with OAuth
- **Type**: Feature
- **Priority**: Must
- **Estimate**: 5
- **Status**: Ready
- **Acceptance Criteria**:
  - [ ] User can log in using GitHub OAuth
  - [ ] User session persists for 24 hours
  - [ ] Failed login shows clear error message
- **Notes**: Requires OAuth app registration in GitHub

Esperado: Todos los elementos tienen títulos, tipos y criterios de aceptación.

En caso de fallo: Los elementos sin criterios de aceptación se marcan con Estado: New (no Ready). No pueden entrar a un sprint.

Paso 3: Priorizar Usando MoSCoW o Valor/Esfuerzo

Aplicar el marco de priorización elegido:

MoSCoW (predeterminado):

• Must (Debe): El proyecto falla sin esto. No negociable.
• Should (Debería): Importante pero el proyecto puede tener éxito sin ello. Incluir si la capacidad lo permite.
• Could (Podría): Agradable de tener. Incluir solo si no hay impacto en los elementos Must/Should.
• Won't (No): Explícitamente excluido del alcance actual. Documentado para consideración futura.

Matriz Valor/Esfuerzo (alternativa):

	Bajo Esfuerzo	Alto Esfuerzo
Alto Valor	Hacer Primero (Victorias Rápidas)	Hacer Segundo (Grandes Apuestas)
Bajo Valor	Hacer Tercero (Relleno)	No Hacer (Sumideros de Dinero)

Ordenar la tabla del backlog: primero los elementos Must (por valor dentro de Must), luego Should, luego Could.

Esperado: Cada elemento tiene una prioridad. El backlog está ordenado por prioridad.

En caso de fallo: Si los interesados no están de acuerdo en las prioridades, escalar las decisiones Must vs Should al patrocinador del proyecto.

Paso 4: Refinamiento — Dividir, Estimar y Refinar

Revisar los elementos para su disposición para el sprint. Para cada elemento:

1. Dividir si la estimación es >8 puntos (o >1 semana de esfuerzo): descomponer en 2-4 elementos más pequeños
2. Estimar usando la escala elegida del proyecto
3. Refinar criterios de aceptación vagos convirtiéndolos en condiciones verificables
4. Marcar como Ready cuando el elemento tenga título, criterios de aceptación, estimación y sin bloqueadores

Documentar la división:

**Split**: B-003 split into B-003a, B-003b, B-003c (original archived)

#### B-003a: Set Up Database Schema
- **Type**: Task
- **Priority**: Must
- **Estimate**: 3
- **Status**: Ready
- **Acceptance Criteria**:
  - [ ] Users table created with email, name fields
  - [ ] Migrations run successfully on dev environment

#### B-003b: Implement User CRUD Operations
- **Type**: Task
- **Priority**: Must
- **Estimate**: 5
- **Status**: Ready
- **Acceptance Criteria**:
  - [ ] Create user endpoint returns 201 with user object
  - [ ] Update user endpoint validates required fields

Esperado: Todos los elementos Must y Should están en estado Ready.

En caso de fallo: Los elementos que no pueden estimarse necesitan un Spike (tarea de investigación con tiempo fijo) añadido al backlog.

Paso 5: Actualizar el Resumen y Archivar

Actualizar las estadísticas de resumen. Mover los elementos Done y Cancelled a una sección de archivo:

### Archive
| ID | Title | Status | Sprint | Completed |
|----|-------|--------|--------|-----------|
| B-001 | Enable User Login with OAuth | Done | S-003 | 2025-03-15 |
| B-004 | Add Dark Mode Theme | Cancelled | — | 2025-03-10 |

Actualizar el resumen contando los elementos en cada estado:

# Count Ready items
grep "| Ready |" BACKLOG.md | wc -l

# Count In Progress items
grep "| In Progress |" BACKLOG.md | wc -l

# Count Done items
grep "| Done |" BACKLOG.md | wc -l

Esperado: Las estadísticas de resumen coinciden con los recuentos reales de elementos. La sección de archivo contiene todos los elementos cerrados.

En caso de fallo: Si los recuentos no coinciden, recontarlos buscando valores de Estado y actualizar el resumen manualmente.

Validación

• BACKLOG.md existe con estructura estándar
• Cada elemento tiene un ID único, título, tipo, prioridad y estado
• Todos los elementos Must y Should tienen criterios de aceptación
• Los elementos están ordenados por prioridad (primero Must, luego Should, luego Could)
• Ningún elemento estimado en >8 puntos sin haber sido dividido
• Las estadísticas de resumen son precisas
• Los elementos Done/Cancelled están archivados

Errores Comunes

• Sin criterios de aceptación: Los elementos sin criterios no pueden verificarse como terminados. Cada elemento necesita al menos 2 criterios verificables.
• Todo es prioridad Must: Si >50% de los elementos son Must, las prioridades no son reales. Forzar un ranking dentro de Must.
• Elementos zombi: Los elementos que llevan meses en el backlog sin avance deben reevaluarse o cancelarse.
• Estimaciones sin contexto: Los puntos de historia son relativos — un equipo debe tener un elemento de referencia (por ejemplo, "B-001 es nuestro elemento de referencia de 3 puntos").
• La división crea fragmentos: Al dividir, asegurarse de que cada elemento hijo sea entregable y valioso de forma independiente.
• El backlog como basurero: El backlog no es una lista de deseos. Podar regularmente los elementos que ya no se alinean con los objetivos del proyecto.
• Dependencias faltantes: Anotar los elementos bloqueantes en el campo Notes. Un elemento bloqueado no debe marcarse como Ready.

Habilidades Relacionadas

• draft-project-charter — el alcance del acta alimenta la creación inicial del backlog
• create-work-breakdown-structure — los paquetes de trabajo de la EDT pueden convertirse en elementos del backlog
• plan-sprint — la planificación del sprint selecciona de la parte superior del backlog
• generate-status-report — el burn-down del backlog alimenta los informes de estado
• conduct-retrospective — los elementos de mejora de la retrospectiva se retroalimentan en el backlog