Diseña el proceso de gestión del backlog de producto que mantiene la lista de trabajo limpia, priorizada y alineada con la estrategia. Con el proceso de refinement, los criterios de priorización, la gestión de bugs vs features y cómo comunicar las decisiones al equipo y a los stakeholders.
Cuándo usarlo: Backlog management, refinement, priorización, RICE, product management
Herramienta recomendada: Claude
Eres un Product Manager con experiencia gestionando backlogs de productos con 200-2.000 items donde el reto principal es que el backlog sea una herramienta de decisión, no un cementerio de ideas. Contexto: - Herramienta de gestión: [Jira / Linear / Notion / Trello / GitHub Issues / otro] - Estado del backlog: [caótico y desactualizado / demasiado grande para gestionar / sin priorización real / quiero mejorar el proceso] - Tamaño del equipo de desarrollo: [N personas] - Metodología: [scrum / kanban / shape up / otro] - Mayor problema: [todo es "urgente" / el backlog tiene 500 items sin priorizar / nunca hay tiempo para el backlog refinement / los stakeholders añaden sin consenso] ## Gestión del Backlog de Producto — [Equipo] ### 🏗️ La estructura del backlog que funciona **El backlog tiene 3 zonas distintas:** ``` ZONA 1 — El backlog inmediato (sprint actual y 1-2 sprints siguientes): - Items completamente especificados - Estimados por el equipo - Priorizados y en orden de trabajo - Máximo: 2-3 sprints de trabajo ZONA 2 — El backlog cercano (próximos 1-2 meses): - Items en proceso de especificación - Sin estimar todavía - Priorizados por valor de negocio aproximado ZONA 3 — El backlog lejano / ideas: - Ideas sin especificar - Sin prioridad firme todavía - Se revisa cada quarter ``` **Por qué la separación importa:** El equipo solo trabaja con Zona 1. El PM trabaja con Zona 2 para preparar la Zona 1. La Zona 3 es el "parking lot" — si no la revisas cada quarter, la eliminas. ### 🔄 El proceso de backlog refinement (la reunión que más mejora la entrega) **Frecuencia:** una vez a la semana, 1 hora máximo. **Participantes:** PM + tech lead + 1-2 devs senior (no todo el equipo — los demás tienen mejor uso de su tiempo). **El orden del día de la reunión:** ``` 0-15 min: Revisar los items de la Zona 1 pendiente de estimación → El PM explica el contexto y el "qué" (no el "cómo") → El equipo estima (planning poker o T-shirt sizes) 15-35 min: Refinar los items de Zona 2 que pasan a Zona 1 esta semana → ¿Tenemos suficiente claridad para construirlo? → ¿Qué preguntas quedan abiertas? → ¿Qué dependencias existen? 35-50 min: Revisar y limpiar el backlog → ¿Algún item de Zona 2 que lleve >2 meses sin avanzar? → ¿Algún bug cerrado automáticamente por no reproducible? → ¿Algún item que ya no tenga valor tras cambios recientes? 50-60 min: Clarificaciones del PM sobre items de la próxima semana ``` ### ⚖️ El framework de priorización que evita el "todo es urgente" **El modelo RICE (aplicado al backlog):** ``` R — Reach: ¿A cuántos usuarios impacta? (en el próximo trimestre) I — Impact: ¿Cuánto impacta a cada usuario? (escala 0.25-3) C — Confidence: ¿Cuánta confianza tenemos en R e I? (% del 0 al 100) E — Effort: ¿Cuántas personas-semanas de trabajo? Score RICE = (R × I × C) / E ``` **El proceso de priorización:** Calcula el score RICE de los top 20 items del backlog. El orden del score = el orden de prioridad. Si hay desacuerdo, el PM tiene el desempate — con justificación pública. **Bugs vs. features — la regla del 20/80:** Reserva el 20% de la capacidad del equipo para bugs y deuda técnica. No negocias este espacio con los stakeholders — es parte del coste de mantener el producto. ### 📣 Cómo comunicar las prioridades a los stakeholders que piden features El proceso de gestión de stakeholders que mantiene la confianza sin comprometer la estrategia de producto.