Calculadora RICE e ICE para priorizar el backlog

RICE es un marco de priorización descrito por Sean McBride, product manager de Intercom. El equipo necesitaba comparar ideas muy distintas —una funcionalidad nueva, un rediseño, una integración— sin discutir de quién era la idea más importante. La puntuación combina cuatro estimaciones:

• El alcance es un número real en un periodo fijo: «1.800 usuarios nuevos por trimestre verán el tour». Sácalo de la analítica, no de la memoria.
• El impacto usa la escala de Intercom: 3 masivo, 2 alto, 1 medio, 0,5 bajo, 0,25 mínimo. Es deliberadamente no lineal: «masivo» vale tres veces «medio».
• La confianza modera el entusiasmo: 100 % significa datos cuantitativos, 80 % algún respaldo, 50 % sobre todo intuición. Por debajo del 50 % conviene validar antes.
• El esfuerzo es el denominador: cuanto más caro, menor puntuación. Una semana de trabajo son unos 0,25 personas-mes.

La puntuación es «impacto por unidad de esfuerzo». Su valor absoluto no significa nada por sí solo: solo sirve para comparar elementos del mismo backlog con el mismo periodo de alcance.

ICE lo popularizó Sean Ellis, creador del término growth hacking. Está pensado para un flujo constante de ideas de crecimiento, cuando no hay tiempo para contar alcance y personas-mes. Cada idea recibe tres notas de 1 a 10:

En «Hacking Growth», Ellis y Brown promedian las notas; muchos equipos las multiplican. La diferencia importa: el producto castiga mucho más una nota baja. Una idea 9 · 9 · 1 obtiene 81 de 1000 multiplicando y 6,3 de 10 promediando, así que por la media supera a una idea equilibrada 6 · 6 · 6 (216 y 6). La calculadora admite ambas: elige una y mantenla en todo el backlog.

La debilidad de ICE es la subjetividad: un «7 de 10» significa cosas distintas para cada persona. Acordad ejemplos de referencia para cada nota y puntuad juntos.

• RICE encaja en un backlog trimestral: elementos de distinto tamaño, analítica para el alcance y estimaciones de ingeniería.
• ICE encaja en la reunión semanal de growth: muchos experimentos baratos y una decisión rápida.
• El modelo Kano responde otra pregunta: cómo percibirán los usuarios una funcionalidad. Úsalo antes de RICE para estimar mejor el impacto; puedes analizar una encuesta en el analizador de encuestas Kano.
• MoSCoW (must, should, could, won’t) sirve para fijar el alcance de una versión, pero no ordena dentro de cada grupo.

Errores frecuentes

• Periodos de alcance distintos. Un elemento con alcance mensual y otro anual: el segundo puntúa doce veces más sin motivo.
• Impacto sobre nada concreto. Fija un objetivo del trimestre —activación, retención, ingresos— y mide el impacto frente a él.
• Confianza del 100 % por costumbre. Si ningún dato respalda las estimaciones, usa 50 %. Ese multiplicador protege el backlog de las ideas favoritas.
• Seguir el ranking a ciegas. La fórmula ignora dependencias, deuda técnica, compromisos con clientes y estrategia.
• No revisar la estimación. Tras el lanzamiento, compara la previsión con la realidad en la calculadora de adopción de funcionalidades y comprueba el efecto con la calculadora de tests A/B.

1. McBride S. RICE: Simple prioritization for product managers. Intercom Blog — descripción original del método y de las escalas de impacto y confianza.
2. Ellis S., Brown M. Hacking Growth: How Today's Fastest-Growing Companies Drive Breakout Success. Crown Business, 2017 — puntuación ICE.
3. Cagan M. Inspired: How to Create Tech Products Customers Love. 2nd ed. Wiley, 2017.
4. Clegg D., Barker R. Case Method Fast-Track: A RAD Approach. Addison-Wesley, 1994 — origen del método MoSCoW.