Hace unos meses estuve en una sesión de PI planning donde un equipo de doce personas discutió durante cuarenta minutos si un botón de "ver alternativas de producto" era más importante que un botón de "notify me" cuando un item está agotado. Los dos PMs tenían slides. Los dos tenían datos. Los dos estaban convencidos. La conversación terminó como siempre terminan esas conversaciones; ganó la persona que gritó más fuerte, y el resto volvió a su portátil con un resentimiento silencioso.
Esa reunión es la razón por la que reconstruí nuestra Calculadora WSJF. No porque al mundo le haga falta otra herramienta de priorización de backlog, sino porque me harté de ver equipos inteligentes tirar un trimestre entero discutiendo sobre sensaciones cuando la matemática existe desde los años 80.
El truco que nadie te cuenta sobre priorización
La mayoría piensa que priorizar es elegir lo más valioso. No lo es. Es elegir aquello donde valor dividido por tamaño es más alto. Esa distinción suena pedante hasta que te das cuenta de que es la diferencia entre entregar ocho pequeños aciertos en un trimestre o entregar una única "iniciativa estratégica" pesadísima que nadie quería del todo.
Esa es la tesis entera de Weighted Shortest Job First. Puntúas cada item del backlog en dos cosas; cuánto cuesta retrasarlo, y cuán grande es el trabajo. Luego divides. Gana la puntuación más alta. Ya está. Sin debates de story points a las 9 de la mañana un lunes, sin "¿la página de login es un 3 o un 5?", sin fingir que tu intuición es una metodología.
WSJF = Coste del Retraso / Tamaño del Trabajo
Don Reinertsen popularizó esto en The Principles of Product Development Flow, que yo llamaría el mejor libro de agile jamás escrito si la frase "libro de agile" no hiciera que la mayoría de ingenieros mirasen la ventana más cercana. En realidad es un libro de teoría de colas disfrazado de libro de management, que es precisamente por lo que es tan bueno.
El Coste del Retraso son tres cosas, no una
Aquí es donde la mayoría de hojas de cálculo WSJF se equivocan. El Coste del Retraso no es un único número. Es la suma de tres preguntas muy distintas:
- Valor de Negocio. Si lo entregásemos mañana, ¿cuánto le importaría a los usuarios o al negocio? Ingresos, retención, un OKR concreto. Concreto cuando puedas, relativo cuando no.
- Criticidad Temporal. ¿El valor se degrada con el tiempo? Una feature de Black Friday lanzada en diciembre vale aproximadamente cero. Una fecha de cumplimiento normativo que no cumples vale menos que cero.
- Reducción de Riesgo / Habilitación de Oportunidad. ¿Esto desbloquea otra cosa o elimina incertidumbre? El trabajo aburrido de infraestructura vive aquí, y normalmente es donde se entierra.
Suma esos tres. Eso es Coste del Retraso. Divide por Tamaño del Trabajo. Eso es WSJF. La razón por la que funciona no es que los números sean precisos; es que la conversación se vuelve precisa. Ya no puedes fingir que un spike de reducción de riesgo es una feature de ingresos. Cada item tiene que justificarse en tres ejes antes de recibir una puntuación.
Por qué el tamaño relativo gana siempre a las horas
La otra trampa es cómo estimas el tamaño. La gente quiere estimar en días. No lo hagas. Los seres humanos somos terribles estimando duración, y tenemos décadas de investigación conductual demostrándolo; la ley de Parkinson por sí sola debería bastar para asustarte. Lo que los humanos hacemos decentemente es comparar dos cosas y decir "esa es más grande que la otra".
Así que puntúa en Fibonacci (1, 2, 3, 5, 8, 13, 20) o tallas de camiseta (XS, S, M, L, XL, XXL). Los saltos importan; pasar de 5 a 8 fuerza una conversación que "4 días vs 5 días" no fuerza. Nuestra herramienta soporta las dos cosas porque los equipos discuten sobre esto, y la discusión no merece la pena. Elige una. Sigue.
Lo que hace la herramienta de verdad
La Calculadora WSJF corre en tu navegador. Nada sale de tu máquina. Soy obsesivo con esto para herramientas de product management en particular; tu roadmap es precisamente el tipo de cosa que no quieres viviendo en el servidor de otro.
Esto es lo que incorporamos después de ver a equipos usándola de verdad:
- Plantillas para dominios habituales. E-commerce, SaaS, plataforma interna, industria regulada. Empiezas desde algo que ya tiene sentido.
- Análisis What-if. Infla el tamaño del top 1 un 25%. ¿Cambia el orden? Si sí, tu prioridad principal es frágil; re-estima antes de comprometerte.
- Indicador de robustez. Si las tres mejores puntuaciones WSJF están a menos del 10% entre sí, trátalas como equivalentes y deja que la capacidad del equipo decida. La herramienta te lo muestra en tiempo real, así dejas de fingir que un 4,20 es significativamente mayor que un 4,10.
- Enlaces compartibles. Copia una URL, pégala en las notas del PI planning, todo el mundo carga el mismo estado del backlog. Sin exportaciones de Jira, sin CSVs vagando por Slack.
- Exportación a CSV y PDF. Porque algunos stakeholders solo se fían de un PDF.
Cuándo WSJF es la respuesta equivocada
Te ahorro un error que yo mismo he cometido. WSJF no es un framework universal de priorización. Es la herramienta correcta cuando:
- Tienes 15 o más items de backlog razonablemente comparables.
- Tu equipo hace entrega continua con ciclos cortos.
- El coste del retraso varía de verdad entre items (unos son sensibles al tiempo, otros no).
Es la herramienta equivocada cuando:
- Tienes una única apuesta estratégica y tres tickets de soporte. Haz la apuesta estratégica.
- Todo es igual de urgente. Entonces nada lo es, y tienes un problema de gestión, no de priorización.
- Estás intentando decidir entre dos productos. Eso es una pregunta de Kano o de portfolio.
Para decisiones binarias de dentro/fuera, tira de MoSCoW o de la matriz de Eisenhower. Para ranking de features de producto de consumo con una fórmula más simple, RICE es más amigable. Construí versiones de los tres; cada uno resuelve una forma ligeramente distinta del problema.
El ritual de reunión que sí funciona
WSJF se rompe cuando se convierte en un ritual. La calculadora hace la matemática; los humanos tienen que hacer la conversación. Este es el bucle que he visto funcionar:
- Puntúa primero el Coste del Retraso, en grupo. Usa planning poker para hacer aflorar los desacuerdos. Si dos personas puntuaron 3 y 13, eso es interesante; indaga.
- Puntúa el Tamaño del Trabajo al final. Si conoces el tamaño antes, ancla tu estimación de valor. Los humanos somos perezosos así.
- Lee el top 3 en voz alta. Si alguien arruga la cara, re-puntuad.
- Cierra y entrega. No re-puntúes a mitad de sprint. Todo el sentido de esto es que el tú de ayer y el de hoy tenían intuiciones distintas pero la matemática no se movió.
Para compromisos de horizonte más largo, empareja WSJF con forecasting probabilístico. Escribí una pieza entera sobre forecasting Monte Carlo para entrega ágil que encaja muy bien; una herramienta te dice qué hacer después, la otra te dice cuándo vas a terminar de verdad.
La parte que me sorprendió
Cuando publiqué la calculadora esperaba que la usaran los ingenieros. Resultó que los product managers son los usuarios más intensos, y lo que más les gusta no es la puntuación. Es el rastro de auditoría. Cada ranking tiene las tres sub-puntuaciones visibles; cuando un stakeholder pregunta "¿por qué mi feature no está arriba?", el PM señala un número y dice "porque tu Criticidad Temporal es S y tu Tamaño del Trabajo es XL". La conversación acaba en un minuto, no en una semana.
Ese es el punto real de cualquier herramienta de priorización. No sustituir el juicio. Hacer el juicio visible lo suficiente como para que la persona más ruidosa no pueda sobrescribir al resto.
Pruébala aquí: kitmul.com/es/agile-project-management/wsjf-calculator. Es gratis, corre en tu navegador y tu backlog sigue siendo tuyo.