Priorización: qué se hace primero y por qué
Las seis estrategias para ordenar el trabajo, y las técnicas que las aplican: MoSCoW, WSJF y coste del retraso, valor frente a esfuerzo, Kano, priorización por riesgo y opportunity scoring.
- Elegir la estrategia de priorización adecuada a una situación (valor, riesgo, coste del retraso, dependencias, esfuerzo, aprendizaje).
- Usar MoSCoW para negociar alcance, sabiendo que es una semántica y no una estrategia.
- Calcular WSJF y ordenar un backlog con él.
- Clasificar funciones con el modelo de Kano y con la matriz valor/esfuerzo.
Diapositivas 37-40 del Tema 1, y el temario las cita expresamente en el índice ("Priorización (MoSCoW, WSJF)"). Espera preguntas de aplicar: "¿qué estrategia usarías aquí?", "¿qué significa Won't?", "calcula el WSJF". Y una idea que se repite: la priorización debe ser explícita y revisable.
1. Por qué priorizar
No todo puede hacerse primero. La prioridad debe reflejar valor, urgencia, riesgo y coste, y debe ser explícita y revisable.Tema 1, diap. 37.
¿Por qué es tan importante? Vuelve a las restricciones de la lección 1. Cuando el plazo es fijo (TusBus: la feria), la única variable que se puede mover sin destrozar la calidad es el alcance. Y para recortar alcance con sentido necesitas saber de antemano qué es lo menos importante. Priorizar es preparar la decisión de recorte antes de que haga falta.
- Explícita: escrita y compartida, no en la cabeza del JP. Así el cliente sabe qué se sacrificará si hay problemas, y no hay sorpresas.
- Revisable: la información cambia (aprendes, el mercado cambia, un riesgo se materializa). Una prioridad fijada en enero y nunca revisada es una apuesta, no una gestión.
2. Seis estrategias
No existe una única estrategia para priorizar. Cada una responde a una pregunta distinta:Tema 1, diap. 38.
| Estrategia | Lo primero es… | Cuándo tiene sentido | En TusBus |
|---|---|---|---|
| Valor | Lo que aporta más valor | Casi siempre como base; sobre todo si puedes entregar en partes | Tiempo de llegada antes que favoritos |
| Riesgo | Lo más arriesgado | Cuando un fallo técnico podría hundir el proyecto; mejor saberlo pronto | Integración con el GPS (¿datos fiables?) antes que el diseño visual |
| Coste del retraso | Lo que más cuesta posponer | Fechas legales, eventos, ventanas de mercado | Lo imprescindible para la feria; lo demás puede esperar a septiembre |
| Dependencias | Lo que desbloquea otras funciones | Cuando hay piezas de las que cuelga el resto | El servicio de ingesta GPS, del que dependen ETA, mapa y avisos |
| Esfuerzo | Resultados rápidos (quick wins) | Para ganar confianza del cliente o del equipo al principio | Listado de paradas con horarios teóricos: fácil y ya útil |
| Aprendizaje | Lo que reduce incertidumbre | Cuando no sabes si algo funcionará o si los usuarios lo quieren | Un prototipo con 20 usuarios reales para ver si entienden la pantalla |
Riesgo y aprendizaje se parecen mucho: ambos adelantan lo incierto. La diferencia: "riesgo primero" ataca lo que puede salir mal; "aprendizaje primero" ataca lo que no sabemos (que puede ser una oportunidad). Ambos aplican la idea de la lección 1: reducir la incertidumbre cuanto antes.
En la práctica se combinan: TusBus empezaría por la integración GPS (riesgo + dependencia), seguiría con el tiempo de llegada (valor + coste del retraso) y metería algún quick win para la primera demo al ayuntamiento.
3. MoSCoW
MoSCoW no proporciona una estrategia, sino una semántica estándar para representar la prioridad de forma explícita.Tema 1, diap. 40. Origen: método DSDM (Dai Clegg, Oracle, 1994); ver MoSCoW method. Es decir: te da cuatro palabras con significado acordado, pero no te dice cómo decidir en cuál va cada cosa (eso lo decides con una de las estrategias anteriores).
| Categoría | Significado | Prueba para saber si es de esta categoría |
|---|---|---|
| Must have | Imprescindible | Sin esto, ¿la entrega no sirve, es ilegal o no es segura? Si se puede "apañar" con un rodeo, no es Must. |
| Should have | Importante, no imprescindible | Duele no tenerlo, pero hay alternativa temporal. |
| Could have | Deseable | Mejora la experiencia; nadie lo echará mucho de menos. |
| Won't have (this time) | No se hará ahora | Acordado que queda fuera de esta entrega. No significa "nunca". |
Es útil para negociar alcance y gestionar expectativas: si el plazo aprieta, se sacrifican primero los Could, luego los Should; los Must no se tocan. El cliente lo sabe desde el principio. Y el Won't es tan valioso como el Must: es el "out of scope" de la lección 3 en versión priorizada.
DSDM recomienda que los Must no superen aproximadamente el 60 % del esfuerzo de una entrega, y que haya en torno a un 20 % de Could. Así, si las cosas van mal, hay margen para sacrificar sin tocar lo imprescindible. Si el 95 % de lo pedido es "Must", la priorización no está hecha: el cliente está diciendo "todo es importante", que equivale a no priorizar.
TusBus para la feria: M: tiempo de llegada por parada, mapa de paradas, cumplimiento RGPD. S: favoritos, avisos de incidencias. C: modo oscuro, widgets. W: venta de billetes, rutas multimodales.
4. Coste del retraso y WSJF
El coste del retraso (Cost of Delay, CoD) es el impacto económico o temporal de retrasar algo.Tema 1, diap. 39. El concepto lo popularizó Don Reinertsen (The Principles of Product Development Flow, 2009). Ejemplo: una función que genera 10.000 €/mes, retrasada dos meses, cuesta 20.000 €. Una función ligada a la feria de agosto, retrasada a septiembre, pierde casi todo su valor.
WSJF (Weighted Shortest Job First, "primero el trabajo más corto ponderado") combina el coste del retraso con el tamaño del trabajo. Es la técnica de priorización de SAFe:Fuente primaria: SAFe, WSJF.
Cada componente se puntúa de forma relativa (normalmente con la serie de Fibonacci modificada: 1, 2, 3, 5, 8, 13, 20), comparando los elementos entre sí. Se hace primero el de mayor WSJF.
La intuición: si dos trabajos valen lo mismo, haz antes el más corto, porque empieza a dar valor antes. Si dos trabajos duran lo mismo, haz antes el que más cuesta retrasar.
| Función TusBus | Valor | Crit. temporal | Riesgo/Oport. | CoD | Tamaño | WSJF |
|---|---|---|---|---|---|---|
| Tiempo de llegada | 20 | 20 | 8 | 48 | 13 | 3,7 |
| Ingesta GPS | 5 | 13 | 20 | 38 | 8 | 4,75 |
| Favoritos | 8 | 3 | 1 | 12 | 3 | 4,0 |
| Venta de billetes | 13 | 2 | 3 | 18 | 20 | 0,9 |
Orden: ingesta GPS (4,75) → favoritos (4,0) → tiempo de llegada (3,7) → billetes (0,9). Fíjate en dos cosas. La ingesta GPS sale primera por su alta reducción de riesgo y por desbloquear el resto, aunque tenga poco valor directo. Y favoritos sale antes que el tiempo de llegada porque es pequeño, aunque el tiempo de llegada sea lo más valioso. Eso no es un error de WSJF: maximiza el valor entregado por unidad de tiempo. Pero si el tiempo de llegada es imprescindible para la feria, MoSCoW lo marca como Must y el juicio del gestor manda: las técnicas ayudan a decidir, no deciden por ti.
5. Valor frente a esfuerzo
La técnica más sencilla: dos ejes, valor y esfuerzo.Tema 1, diap. 39.
| Esfuerzo bajo | Esfuerzo alto | |
|---|---|---|
| Valor alto | Quick wins: hazlo ya | Grandes apuestas: planifícalo bien, divídelo |
| Valor bajo | Rellenos: si sobra tiempo | Pozos sin fondo: evítalo |
Su ventaja es la comunicación: se entiende en una pizarra con el cliente. Su debilidad: ignora riesgo, dependencias y urgencia.
6. Priorización por riesgo
Ordena por probabilidad × impacto de lo que podría salir mal.Tema 1, diap. 39. La exposición al riesgo se trata a fondo en la lección 13. La idea viene de los ciclos de vida iterativos guiados por riesgo (el modelo en espiral de Boehm): en cada iteración se ataca el mayor riesgo pendiente. En TusBus: si la precisión de los tiempos es el mayor riesgo, la primera iteración debe demostrar con datos reales que se puede conseguir error < 60 s. Si no se puede, mejor saberlo en marzo que en julio.
7. Modelo de Kano
Kano clasifica las funciones según cómo afectan a la satisfacción del cliente:Noriaki Kano, 1984. Ver Kano model.
| Categoría | Si está | Si falta | TusBus |
|---|---|---|---|
| Básicas (must-be) | Nadie lo agradece, se da por hecho | Gran insatisfacción | Que la app no se cuelgue; que los tiempos sean de verdad |
| De desempeño (lineales, one-dimensional) | Más es mejor, proporcionalmente | Insatisfacción proporcional | Precisión de la estimación; velocidad de carga |
| Atractivas (delighters) | Sorprenden y encantan | Nadie las echa de menos | Aviso "sal ya de casa, tu bus llega en 4 min" |
| Indiferentes | Da igual | Da igual | Elegir el color del icono |
| Inversas | Molestan | Mejor | Notificaciones publicitarias |
Dos lecciones de gestión: primero las básicas (sin ellas, lo demás no importa), luego las de desempeño, y algún atractivo para diferenciarse. Y: las categorías se desplazan con el tiempo; lo que hoy es atractivo (el aviso push) mañana es básico porque todas las apps lo tienen.
8. Opportunity scoring
Compara la importancia que el cliente da a algo con su satisfacción actual.Tema 1, diap. 39. Técnica de Anthony Ulwick (Outcome-Driven Innovation). Las mayores oportunidades son lo muy importante y mal resuelto hoy. Si los viajeros dicen que saber cuándo llega el bus es importantísimo (9/10) y que hoy están poco satisfechos (2/10), hay una gran oportunidad. Si dicen que ver el horario teórico es importante (7/10) pero ya están satisfechos con el PDF de la web (7/10), hay poca.
Fórmula habitual: oportunidad = importancia + máx(importancia − satisfacción, 0).
9. Cuál usar
| Situación | Técnica natural |
|---|---|
| Negociar con el cliente qué entra en la fecha fija | MoSCoW |
| Ordenar un backlog grande con fechas y valores económicos distintos | WSJF / Cost of Delay |
| Pizarra rápida con el equipo | Valor vs. esfuerzo |
| Tecnología nueva, mucho riesgo técnico | Priorización por riesgo |
| Decidir qué funciones diferenciarán el producto | Kano, opportunity scoring |
- "MoSCoW es una estrategia de priorización": según el temario, es una semántica para expresar la prioridad, no una estrategia para decidirla.
- "Won't = nunca se hará": no, es no se hará ahora (en esta entrega).
- "WSJF = valor / esfuerzo": incompleto. El numerador es el coste del retraso (valor + criticidad temporal + reducción de riesgo/oportunidad), no sólo el valor.
- "La prioridad se fija al principio y no se toca": debe ser revisable.
Práctica
¿Qué estrategia de priorización aplica cada decisión?
- Empezamos por la integración con el GPS porque, si falla, el proyecto no tiene sentido
- Primero el servicio de usuarios, porque pagos, perfil y avisos lo necesitan
- Primero lo que exige la nueva ley, que entra en vigor en dos meses
- Primero el listado de paradas: es fácil y el cliente verá algo útil ya
- Primero un prototipo con usuarios para ver si entienden la pantalla
- Primero la función que más usuarios han pedido y más ingresos genera
Según el temario, ¿qué es exactamente MoSCoW?
- Una estrategia que ordena el trabajo por su coste del retraso
- Una semántica estándar para expresar la prioridad explícitamente
- Una fórmula que divide el valor de negocio entre el esfuerzo
- Una técnica que mide la satisfacción del cliente con cada función
En MoSCoW, ¿qué significa que una función esté en Won't?
- Que el cliente la ha descartado y no se hará en ninguna versión
- Que se hará sólo si el equipo termina antes de lo previsto
- Que no se hará en esta entrega, aunque podría hacerse más adelante
- Que es técnicamente imposible con la arquitectura elegida
Una función tiene valor de negocio 8, criticidad temporal 13, reducción de riesgo 3 y tamaño 6. ¿Cuál es su WSJF?
Dos funciones tienen el mismo coste del retraso (20). A tiene tamaño 10 y B tamaño 4. Según WSJF, ¿cuál va primero y por qué?
- A, porque al ser más grande aporta más valor total al terminarla
- B, porque al ser más corta empieza a entregar su valor antes
- Da igual el orden, porque las dos tienen el mismo coste del retraso
- A, porque los trabajos grandes tienen más riesgo y conviene adelantarlos
Clasifica estas funciones de una app de comida a domicilio según Kano.
- El pedido llega a la dirección correcta
- Cuanto menor sea el tiempo de entrega, mejor
- Te regala un postre sorpresa en tu cumpleaños
- Poder elegir el color de fondo del perfil
El cliente marca el 90 % de los requisitos como Must. ¿Qué debería hacer el JP?
- Aceptarlo y planificar todo como imprescindible, porque decide el cliente
- Reclasificar él mismo los requisitos para dejar los Must en un 60 %
- Rechazar el proyecto, porque así no es posible planificar con MoSCoW
- Revisar con el cliente qué es de verdad imprescindible para la entrega
Prioriza con MoSCoW cinco funciones de una app de reservas de pistas de pádel para un club que la quiere antes de la temporada (septiembre), y justifica el Must y el Won't.
Repaso espaciado · lecciones 3-4
¿Qué detecta un requisito que aparece en la matriz de trazabilidad sin ninguna prueba asociada?
- Un requisito que no tiene origen en ningún objetivo del proyecto
- Un requisito sin cobertura, cuyo cumplimiento no está verificado
- Un requisito que se ha implementado dos veces en módulos distintos
- Un requisito que debe pasar a Won't en la siguiente priorización
¿Cuál de estos objetivos NO es SMART?
- Reducir un 30 % las llamadas al servicio de atención antes de junio
- Alcanzar 5.000 usuarios activos al mes al final del primer trimestre
- Mejorar la experiencia de los clientes con el nuevo portal web
- Publicar la versión 1.0 en las dos tiendas el 15 de marzo de 2027
Para profundizar
SAFe · Weighted Shortest Job First: explica el coste del retraso y el cálculo con ejemplos (inglés, 10 min). Para MoSCoW, la entrada MoSCoW method resume la regla del 60 % de DSDM. Para Kano, Kano model.
Un buen ejercicio con un asistente: dale la lista de requisitos de tu práctica y pídele que te pregunte qué estrategia usarías para ordenarlos y por qué; luego compara.
Resumen imprimible: Referencia · Fundamentos.