Hay dos formas de priorizar un backlog.
La común: te sientas con los stakeholders, cada uno defiende su feature, gana el que grita más fuerte o tiene el título más alto. Al sprint siguiente, el equipo construye algo que nadie usa.
La de este módulo: le asignas un número a cada feature, y el número decide. No la política. No la intuición. No el "es que el VP lo pidió".
RICE. WSJF. Cost of Delay. Kano. No son siglas de moda: son algoritmos que cualquier PM debería poder calcular en cinco minutos por épica.
Cuando tu jefe pregunte "¿por qué esta épica va primero?", no dirás "lo acordamos en la reunión". Dirás: "porque su Cost of Delay es de $45,000/semana y la siguiente es de $12,000. ¿Quieres ver la fórmula?"
Vamos.
Cuando tienes 47 épicas, priorizar por urgencia (lo que suena más fuerte hoy) te hace perder. Prioriza por valor: lo que mueve la aguja esta semana. El número decide.
2.1. Los 4 Algoritmos de Priorización (Cuándo Usar Cada Uno)
Ningún algoritmo es universal. Cada uno responde una pregunta diferente. Usa este árbol para elegir:
¿Qué necesitas decidir?
| Algoritmo | Pregunta que Responde | Cuándo Usarlo | Cuándo NO Usarlo |
|---|---|---|---|
| RICE | ¿Qué feature da más valor por esfuerzo? | Backlog mixto con features de distinto tamaño e impacto. Ideal para startups y equipos pequeños. | Cuando el tiempo es el factor crítico (lanzamiento con fecha fija). |
| WSJF (Weighted Shortest Job First) | ¿Qué feature entrega más valor en menos tiempo? | Equipos que necesitan entregar rápido. Ideal para SAFe y equipos grandes. | Cuando el tamaño de las features es similar (WSJF no diferencia). |
| Cost of Delay | ¿Cuánto dinero perdemos por no tener esto hoy? | Features con impacto directo en ingresos o costos. Ideal para fintech, banca, e-commerce. | Features sin impacto financiero claro (experimentales, de descubrimiento). |
| Kano | ¿Esto deleitará al usuario o solo es lo mínimo que espera? | Features de experiencia de usuario, diferenciación competitiva. Ideal para producto maduro. | Features operativas o técnicas que el usuario no ve. |
2.2. RICE: Alcance, Impacto, Confianza, Esfuerzo
| Feature (Fintech) | Alcance | Impacto | Confianza | Esfuerzo | RICE |
|---|---|---|---|---|---|
| Pago con QR | 8 | 2 | 0.8 | 4 | 3.2 |
| Historial de transacciones | 10 | 1 | 0.9 | 2 | 4.5 ⭐ |
| Notificaciones push | 7 | 0.5 | 0.5 | 1 | 1.75 |
| Modo oscuro | 6 | 0.25 | 0.8 | 0.5 | 2.4 |
Historial de transacciones (4.5) — aunque su impacto unitario es menor, llega a todos los usuarios y es fácil de construir.
2.3. WSJF: Weighted Shortest Job First
Usado en SAFe. El Cost of Delay = Valor de Negocio + Urgencia + Reducción de Riesgo + Oportunidad. Cada componente se puntúa 1–13 (Fibonacci).
| Feature (Fintech) | Valor | Urgencia | Riesgo | Oport. | CoD | Tamaño | WSJF |
|---|---|---|---|---|---|---|---|
| Pago con QR | 8 | 13 | 3 | 5 | 29 | 20 | 1.45 |
| Historial transacciones | 5 | 5 | 8 | 3 | 21 | 10 | 2.10 |
| Notificaciones push | 3 | 3 | 2 | 8 | 16 | 5 | 3.20 ⭐ |
| Cumplimiento regulatorio | 13 | 8 | 13 | 1 | 35 | 30 | 1.17 |
Notificaciones push (3.20) — pequeño, rápido y abre engagement. El cumplimiento regulatorio vale más, pero es tan grande que conviene hacer primero lo rápido.
2.4. Cost of Delay — El Lenguaje que el Negocio Entiende
El Cost of Delay responde: "¿Cuánto dinero perdemos por cada semana que esta feature no está en producción?"
Ejemplo · "Pago con QR en comercios": ingreso incremental $50,000/sem × margen 3% = $1,500 · + costo evitado de operación manual $5,000/sem.
Cuando presentas un feature con su Cost of Delay al comité de inversión, no estás pidiendo permiso: estás mostrando cuánto cuesta decir que no.
2.5. Kano: Lo Que Deleita vs. Lo Que se Espera
El modelo Kano cruza dos ejes: cuánto está implementada una feature (horizontal) y cuánta satisfacción genera (vertical). Cada categoría se comporta distinto:
| Feature (Fintech) | Categoría Kano | Decisión para el PM |
|---|---|---|
| Pago exitoso sin errores | Esperado | Si falla, los usuarios se van. Prioridad absoluta. |
| Notificación cuando el pago llega | Lineal | A más rápido, mejor. Prioridad media-alta. |
| Resumen semanal de gastos con IA | Encantador | Nadie lo espera, pero al verlo aman la app. Prioridad baja, alto retorno de marca. |
| App con modo oscuro | Indiferente | No mueve la aguja. No priorizar. |
Los Esperados son no-negociables (sin ellos, el producto no funciona). Los Lineales son donde compites. Los Encantadores son tu diferencial —pero nunca los sacrifiques por los Esperados.
2.6. DoR y DoD: Las Puertas de Entrada y Salida
El backlog no es una lista de deseos: es un pipeline. Y todo pipeline necesita una puerta de entrada (DoR) y una de salida (DoD).
- 🟢 Definition of Ready — antes de entrar al sprint
- Tiene un spec asociado (Módulo 3).
- Criterios de aceptación escritos.
- Validada con ≥1 usuario o stakeholder.
- Tiene score de priorización (RICE o WSJF).
- Estimada por el equipo técnico.
- Dependencias externas identificadas.
- 🏁 Definition of Done — para considerarse completa
- El código está en producción (no solo en QA).
- Las pruebas automatizadas pasan.
- La documentación está actualizada.
- La métrica de éxito del spec se puede medir.
- Sin bugs conocidos de severidad crítica/alta.
- Soporte informado del cambio.
El DoD que termina en "código mergeado a main" no es done: es "codeado". Done es cuando el usuario puede usarlo y la métrica se puede medir.
3.1. Construir el Backlog Paramétrico en Google Sheets
Objetivo: Una hoja de cálculo que calcule automáticamente RICE, WSJF y Cost of Delay para cada épica, y reordene el backlog según el algoritmo que elijas.
Paso 1 — Crear la estructura base
Abre sheets.new. Crea las siguientes columnas:
A: ID (F001, F002...)
B: Feature Name
C: Estado (Propuesta | Validando | Lista | En Progreso | Hecha)
D: Cost of Delay ($/semana)
E: Alcance (1-10)
F: Impacto (0.25-3)
G: Confianza (0.2-1)
H: Esfuerzo (puntos o días)
I: RICE Score (=E*F*G/H)
J: Valor Negocio (1-13)
K: Urgencia (1-13)
L: Reducción de Riesgo (1-13)
M: Oportunidad (1-13)
N: CoD Total (=J+K+L+M)
O: Tamaño (días)
P: WSJF (=N/O)
Q: Categoría Kano
Paso 2 — Fórmulas clave
RICE Score (columna I):
=SI.ERROR(E2*F2*G2/H2, 0)
Multiplica alcance × impacto × confianza y divide por esfuerzo. El SI.ERROR maneja divisiones entre cero.
WSJF (columna P):
=SI.ERROR(N2/O2, 0)
Divide el Cost of Delay total entre el tamaño estimado en días.
Prioridad Combinada (nueva columna R):
=SI(O2<=5, "Corto Plazo", SI(O2<=15, "Mediano Plazo", "Largo Plazo"))
Clasifica las features según su tamaño para ayudarte a decidir qué entra al próximo sprint.
Paso 3 — Ordenamiento dinámico con SORT
Crea una segunda pestaña llamada Backlog Priorizado que lea los datos de la primera pestaña y los ordene automáticamente.
En la celda A1 de la segunda pestaña:
=SORT('Features'!A2:R100, 'Features'!I2:I100, FALSE)
Esto toma todas las features de la primera pestaña y las ordena por RICE Score descendente. Cuando actualices un valor en la primera pestaña, el orden cambia solo.
Para ordenar por WSJF en lugar de RICE:
=SORT('Features'!A2:R100, 'Features'!P2:P100, FALSE)
Paso 4 — Formato condicional para visualización rápida
- Si Estado = "Hecha" → tachado, gris.
- Si Cost of Delay > $10,000 → fondo rojo.
- Si RICE > 5 → fondo verde.
- Si RICE entre 2 y 5 → fondo amarillo.
Paso 5 — Celda de control para cambiar algoritmo
En la celda S1 de la primera pestaña, agrega una validación de datos:
Algoritmo Activo: [RICE | WSJF | CoD]
En la segunda pestaña, usa un IF para que el ordenamiento cambie según el algoritmo seleccionado:
=SI('Features'!S1="RICE", SORT('Features'!A2:R100, 'Features'!I2:I100, FALSE),
SI('Features'!S1="WSJF", SORT('Features'!A2:R100, 'Features'!P2:P100, FALSE),
SORT('Features'!A2:R100, 'Features'!D2:D100, FALSE)))
3.2. Integrar con Jira (Opcional)
Si tu equipo usa Jira, puedes mantener tu backlog paramétrico en Sheets como fuente de verdad de priorización y sincronizar manualmente:
- Cada semana, abres el sheet, ves el orden que da el algoritmo.
- Reordenas el backlog en Jira para que coincida.
- Cuando alguien pregunta "¿por qué esta épica va antes?", compartes el link al sheet.
No necesitas integración técnica. El sheet es tu herramienta de decisión. Jira es tu herramienta de ejecución. Mantenlas separadas.
3.3. Ejercicio de Simulación Fintech
Escenario: Eres PM de una fintech que procesa $2M USD/mes en transacciones. Tu equipo tiene capacidad para 20 puntos de historia por sprint (2 semanas). Tienes estas features:
| Feature | Esfuerzo (pts) | Alcance | Impacto | Confianza | Valor Negocio | Urgencia | Riesgo | Oportunidad |
|---|---|---|---|---|---|---|---|---|
| Onboarding con cámara (escaneo de cédula) | 8 | 5 | 3 | 0.6 | 13 | 8 | 13 | 3 |
| Transferencia entre cuentas propias | 3 | 8 | 2 | 0.9 | 8 | 5 | 3 | 5 |
| Dashboard de gastos mensuales | 5 | 6 | 1 | 0.7 | 5 | 3 | 5 | 8 |
| Pago de servicios públicos | 13 | 10 | 2 | 0.5 | 8 | 13 | 8 | 5 |
Calcula RICE y WSJF para cada una, responde: 1. ¿Cuál va primero por RICE? 2. ¿Cuál va primero por WSJF? 3. ¿Son diferentes? ¿Por qué? 4. ¿Cuál elegirías tú y por qué?
(Respuesta al final del módulo.)
4. Cómo Usar Esto para Mejorar tus Procesos Reales
4.1. El Backlog Paramétrico como Escudo Político
Situación real: El VP de Ventas llega con una feature "urgente" que nadie pidió.
Lo que hacías antes: Decías que sí, la metías al sprint, el equipo se atrasaba, y dos meses después nadie la usaba.
Lo que harás ahora: 1. Abres tu backlog paramétrico. 2. Le asignas valores a la feature del VP. 3. Calculas su RICE/WSJF. 4. Le muestras al VP dónde queda en el orden. 5. Le dices: "Podemos ponerla primero si tú autorizas sacar estas 3 features que están arriba. ¿Cuál sacamos?"
Regla: Nunca digas "no". Siempre di "sí, pero ¿qué sacamos?" La hoja de cálculo muestra el costo de cada decisión.
4.2. El Ciclo Semanal de Ingeniería de Backlog
| Día | Actividad | Duración |
|---|---|---|
| Lunes | Ingresar nuevas features al backlog paramétrico | 15 min |
| Martes | Validar valores con data real (analytics, entrevistas) | 20 min |
| Miércoles | Revisar el orden automático y ajustar si algo parece inconsistente | 15 min |
| Jueves | Preparar el sprint: tomar las features de arriba del ranking que quepan en la capacidad del equipo | 15 min |
| Viernes | Compartir el ranking con stakeholders + explicar cambios | 10 min |
Total: 1.25 horas semanales.
4.3. Diagnóstico Rápido: ¿Tu Backlog está Enfermo?
- ¿Tienes features en tu backlog que llevan más de 6 meses sin moverse?
- Sí → O no valen la pena (deberías cerrarlas) o nadie se atreve a matarlas.
-
Si aplicas RICE, las features viejas suelen tener confianza baja. El algoritmo las entierra solas.
-
¿Tu equipo construye lo que el PM prioriza o lo que el stakeholder con más voz pide?
-
Si la prioridad cambia cada semana, no tienes un backlog, tienes una bandeja de entrada.
-
¿Podrías justificar el orden de tu backlog con números?
-
Si no puedes, tu priorización es política, no algorítmica.
-
¿Tienes Definition of Ready y Definition of Done escritos?
- Si no, tu equipo no sabe cuándo algo está listo para empezar ni cuándo está listo para terminar. Cada sprint es una apuesta.
4.4. Entregable del Módulo
Construye tu Backlog Paramétrico en Google Sheets:
Pestaña 1 — Features: - Mínimo 8 features de tu proyecto actual (o simuladas si no tienes). - Columnas completas: ID, Nombre, Estado, CoD, Alcance, Impacto, Confianza, Esfuerzo, RICE, Valor, Urgencia, Riesgo, Oportunidad, CoD Total, Tamaño, WSJF, Categoría Kano. - Fórmulas funcionando en RICE y WSJF. - Formato condicional aplicado.
Pestaña 2 — Backlog Priorizado:
- Ordenamiento automático usando SORT.
- Celda de control para cambiar entre algoritmos (RICE / WSJF / CoD).
Pestaña 3 — DoR y DoD: - Checklist de Definition of Ready (mínimo 5 ítems) para tu equipo. - Checklist de Definition of Done (mínimo 6 ítems) para tu equipo. - Una nota explicando: "Si mi equipo usara estos checklists, ¿qué problema recurrente desaparecería?"
Formato de entrega: Link al Google Sheet con permisos de comentario. Agrega una nota en la celda A1 con un breve análisis: "Basado en mi backlog, la feature más prioritaria por [algoritmo elegido] es [feature] porque [justificación con números]."
Toma 5 épicas reales (o simuladas) y calcula su orden con RICE, WSJF, Cost of Delay y Kano. ¿Coincide el ganador en los cuatro? Si no, explica por qué cada método "ve" algo distinto. Esa es la conversación que tendrás con tu jefe.
- Error: inventar el Confidence de RICE siempre al 100%. Corrección: la confianza baja existe para castigar la falta de evidencia; úsala honestamente o el puntaje miente.
- Error: comparar puntajes RICE entre backlogs de equipos distintos. Corrección: los puntajes solo ordenan dentro del mismo backlog; entre equipos las escalas no son comparables.
- Error: aplicar WSJF sin estimar el Cost of Delay en dinero. Corrección: sin CoD cuantificado, WSJF es una opinión disfrazada de fórmula.
- Error: clasificar features en Kano preguntándole al equipo en vez de a usuarios. Corrección: Kano se valida con usuarios (pregunta funcional + disfuncional); el equipo siempre cree que todo deleita.
- Error: recalcular la priorización todos los días. Corrección: la priorización paramétrica es por sprint o por release; recalcular en caliente devuelve el poder a la política.
| Criterio | No Aprobado (0) | Aprobado (1) | Sobresaliente (2) |
|---|---|---|---|
| 1. Las fórmulas de priorización funcionan correctamente | Las fórmulas tienen errores o no reflejan los algoritmos descritos (RICE, WSJF). Los valores no se actualizan al cambiar los inputs. | Las fórmulas existen y producen números, pero no hay celda de control para cambiar entre algoritmos o el ordenamiento automático no funciona | Las 3 fórmulas (RICE, WSJF, CoD) funcionan, hay una celda desplegable para cambiar el algoritmo de ordenamiento, y el backlog se reordena automáticamente al cambiar cualquier valor |
| 2. Los checklists DoR y DoD son aplicables al equipo real | No hay checklists o son genéricos copiados de internet sin adaptación al contexto del equipo | Existen checklists con ítems razonables pero falta algún ítem crítico que el equipo realmente necesita (ej. "validado con usuario" en DoR) | Los checklists reflejan problemas reales del equipo, tienen ítems específicos accionables (no genéricos), y el PM identifica qué problema recurrente desaparecería al implementarlos |
| 3. Hay evidencia de que el backlog paramétrico cambia decisiones | No hay análisis. El backlog existe pero el PM no demuestra que el algoritmo haya cambiado su percepción de qué debería ir primero | El PM identifica una feature que creía prioritaria pero que el algoritmo muestra como de baja prioridad, pero no explica qué hará con esa información | El PM identifica al menos un caso donde el algoritmo contradijo su intuición, explica por qué confía más en el algoritmo, y describe qué va a hacer diferente esta semana basado en los números |
Aprobación: 2 de 3 criterios en "Aprobado" o superior.
Resultado del ejercicio de simulación (referencia):
| Feature | RICE | Orden RICE | WSJF | Orden WSJF |
|---|---|---|---|---|
| Onboarding con cámara | (5×3×0.6)/8 = 1.125 | 3° | (13+8+13+3)/8 = 4.625 | 2° |
| Transferencia cuentas propias | (8×2×0.9)/3 = 4.8 | 1° | (8+5+3+5)/3 = 7.0 | 1° |
| Dashboard de gastos | (6×1×0.7)/5 = 0.84 | 4° | (5+3+5+8)/5 = 4.2 | 3° |
| Pago de servicios públicos | (10×2×0.5)/13 = 0.77 | 5° | (8+13+8+5)/13 = 2.61 | 4° |
Respuesta: Transferencia entre cuentas propias gana en ambos algoritmos. Es pequeña (3 pts), tiene alta confianza (0.9), alto alcance (8), y un buen balance de valor/urgencia. El onboarding con cámara tiene alto impacto potencial pero baja confianza y alto esfuerzo — necesita validación antes de comprometerse.
Para avanzar al Módulo 6: Toma tu backlog paramétrico y úsalo en la próxima reunión de planificación. Cuando alguien pida cambiar la prioridad, no discutas: abre el sheet, ajusta los valores, y muestra el nuevo orden. No importa si el equipo acepta el orden algorítmico de inmediato. Lo importante es que empieces a tener la conversación en términos de números, no de opiniones.
- Cada algoritmo responde una pregunta distinta: RICE (valor/esfuerzo), WSJF (valor/tiempo), CoD ($ por esperar), Kano (deleite vs. esperado).
- El Cost of Delay traduce prioridad a dinero: el lenguaje que el negocio entiende.
- DoR y DoD convierten el backlog en un pipeline con puertas claras de entrada y salida.
- Un backlog paramétrico cambia la conversación de opiniones a números.
Kit: Backlog y Priorización
| Archivo | Descripción |
|---|---|
| ⬇ backlog-parametrico-template.xlsx | Excel con RICE, WSJF, CoD, Kano + SORT dinámico + selector de algoritmo |