Ir al contenido

OKR

De Scrum Manager BoK
⏱ 6 min  ·  📅 2026
Los OKR (Objectives and Key Results, objetivos y resultados clave) son un sistema de definición y seguimiento de objetivos que conecta la dirección estratégica de una organización con el trabajo concreto de sus equipos. Cada OKR tiene dos componentes: un objetivo cualitativo e inspirador que describe qué se quiere lograr, y entre dos y cuatro resultados clave (KR) medibles que definen cómo se sabrá si se ha alcanzado.

A diferencia de los objetivos SMART, los OKR no son una herramienta de seguimiento de tareas: son una herramienta de alineamiento estratégico y aprendizaje. La pregunta central que responden no es "¿hemos entregado lo que dijimos?" sino "¿hemos generado el impacto que queríamos?".

Origen

El sistema fue desarrollado por Andy Grove en Intel en los años setenta como evolución de la gestión por objetivos (MBO) de Peter Drucker. John Doerr lo aprendió trabajando en Intel y lo introdujo en Google en 1999, cuando la empresa tenía poco más de 40 empleados. Google lo adoptó y lo ha usado desde entonces. La publicación del libro Measure What Matters (Doerr, 2018) popularizó el sistema más allá del sector tecnológico.

De la estrategia al OKR

Los OKRs traducen la estrategia de producto en objetivos para los equipos. La estrategia decide los pocos problemas que de verdad importan; cada objetivo de equipo es uno de esos problemas, y sus KRs miden si la apuesta avanza. Un OKR que no puede rastrearse hasta una decisión de la estrategia queda desconectado, aunque esté bien redactado.

Cuando falta una estrategia previa, los OKRs se llenan de peticiones redactadas como objetivos y se reconocen por tres síntomas: demasiados objetivos, objetivos que reflejan el organigrama y objetivos que nadie sabe justificar. La visión del producto aporta el horizonte; la estrategia decide el camino para acercarse a él, y los OKRs miden si ese camino funciona.

La estructura de un OKR

El objetivo

El objetivo describe la dirección aspiracional: qué se quiere lograr durante el ciclo. Debe ser:

  • Cualitativo: sin números. Los números van en los KRs.
  • Inspirador: debe generar energía y orientar decisiones, no ser un formulario.
  • Claro: cualquier persona de la organización debería poder leerlo y entender hacia dónde va el equipo.
  • No prescriptivo: describe el destino, no el camino. "Convertirnos en la referencia de formación ágil en el mercado hispanohablante" es un objetivo; "lanzar tres nuevos cursos" no lo es: describe actividades, no el impacto que se busca.

Los Key Results

Los resultados clave son la definición operativa del éxito del objetivo. Para redactarlos correctamente:

  • Usar el formato «De X a Y en fecha Z»: expresa un movimiento medible entre dos puntos en el tiempo. "Aumentar la tasa de finalización de cursos del 42% al 60% antes del 30 de junio."
  • Deben medir outcomes (resultados, impactos), no outputs (entregas, tareas). Un KR que usa verbos como "entregar", "lanzar" o "completar" describe trabajo, no impacto.
  • La prueba de los múltiples caminos: un KR mide un resultado cuando múltiples soluciones diferentes podrían lograrlo. Si el KR solo puede lograrse de una manera específica, probablemente está midiendo una tarea.
  • Entre 2 y 4 KRs por objetivo. Más de 4 suelen indicar que el objetivo es demasiado amplio o que se están incluyendo tareas.
  • Definir la fórmula de cálculo: qué se cuenta, en qué población, con qué periodicidad y con qué fuente de datos. Sin ella, el equipo discute sobre los números en lugar de sobre las decisiones.
  • Si no hay datos de partida, estimar una línea de base informada, medir desde el primer día y corregir en el ciclo siguiente, en lugar de esperar al dato perfecto.

Tipos de OKR

Google distingue dos tipos de OKR con lógicas opuestas. Los comprometidos son los que se acuerda alcanzar, ajustando calendarios y recursos si hace falta, y su puntuación esperada es 1,0. Los aspiracionales expresan cómo se querría que fuera el mundo aunque no se sepa bien cómo llegar, y su puntuación media esperada ronda 0,7. What Matters, la organización fundada por John Doerr para difundir los OKRs, ha añadido un tercer tipo, el OKR de aprendizaje, que prioriza descubrir sobre alcanzar una cifra: su KR pasa de «aumentar X» a «descubrir si Y es cierto», y resulta útil en fases tempranas o ante una incertidumbre alta.

Etiquetar cada OKR con su tipo evita leer el mismo número de dos maneras opuestas: un 70 % puede ser excelente en un aspiracional y un fracaso en un comprometido.

Outcome vs. output: la distinción clave

La distinción entre outcome y output es la piedra angular de los OKRs:

  • Un output es algo que se produce: una funcionalidad, un documento, un despliegue. Se puede marcar como "hecho" el día que se entrega.
  • Un outcome es el cambio que ese output genera: un comportamiento diferente del usuario, una métrica de negocio que se mueve, un problema que se resuelve.

Cuando el éxito se define como "lanzar la funcionalidad X", el equipo optimiza para entregar, no para generar valor. La funcionalidad puede desplegarse, el equipo celebra, y sin embargo ningún usuario cambia su comportamiento ni ninguna métrica se mueve. Los OKRs que miden outcomes evitan esta trampa: el equipo no puede declarar éxito hasta que el cambio buscado ocurre en el mundo real.

Un KR es probablemente un output si... Un KR es probablemente un outcome si...
Señales Incluye verbos como "entregar", "lanzar", "implementar". Se puede marcar "hecho" el día del despliegue. Mide un cambio en el comportamiento de usuarios o en métricas de negocio. Múltiples soluciones podrían lograrlo.
Ejemplo (producto digital) "Lanzar el módulo de reportes" "Aumentar el uso semanal de reportes del 18% al 40%"

Indicadores leading y lagging

Los Key Results deben combinar dos tipos de indicadores:

  • Leading indicators (indicadores predictivos): métricas que anticipan el resultado final y permiten actuar mientras todavía hay tiempo durante el ciclo. Ejemplo: "tasa de activación en la primera semana" predice la retención futura.
  • Lagging indicators (indicadores de resultado): métricas que reflejan el resultado final del negocio, pero cuya tendencia solo se conoce cuando el ciclo ya ha terminado. Ejemplo: "revenue recurrente anual".

Un OKR compuesto solo de indicadores lagging no permite tomar decisiones durante el trimestre: cuando detectas que algo va mal, ya es demasiado tarde para corregir. Incluir indicadores leading en los KRs hace que los check-ins sean útiles: el equipo puede ajustar tácticas a tiempo.

El ciclo OKR

Los OKRs habitualmente funcionan con un ciclo trimestral:

  1. Definición (semanas 1-2): el equipo define objetivos y KRs del trimestre. El punto de partida (baseline) de cada KR debe estar documentado.
  2. Check-ins (semanales o quincenales): revisiones cortas y regulares en las que el equipo repasa el avance de cada KR y su confianza en alcanzarlo, y decide qué cambiar. Un check-in no es un reporte de estado, sino una sesión para decidir qué hacer distinto a partir de ahora. Christina Wodtke ancló la práctica en un ritmo semanal en Radical Focus, con los compromisos del lunes y los logros del viernes.
  3. Evaluación final: al cierre del trimestre se puntúa cada KR (habitualmente entre 0 y 1) y se extrae el aprendizaje.

Confianza, no solo avance

El estado de un KR es la confianza del equipo en alcanzarlo, más que su porcentaje de avance: un KR al 60 % estancado puede ir peor que uno al 30 % con buena dinámica. Christina Wodtke propone en Radical Focus una escala de confianza de 1 a 10 en la que un KR exigente arranca en 5, y el semáforo verde, ámbar y rojo es la variante habitual en equipos y herramientas. La confianza solo es útil si se acompaña del supuesto que la sostiene, y solo avisa a tiempo si declarar un riesgo se premia en lugar de castigarse.

La puntuación no es el objetivo: el aprendizaje es el objetivo. Además, la nota se lee según el tipo de OKR. En un OKR aspiracional se espera una media en torno a 0,7, y un KR que se puntúa con 0,3 porque la hipótesis era incorrecta puede enseñar más que uno que llega a 1,0 porque era demasiado fácil. En un OKR comprometido se espera 1,0, y quedarse por debajo exige analizar qué falló en la planificación o en la ejecución, sin ánimo de castigo. Alcanzar el número tampoco equivale a haber logrado el outcome, por lo que el cierre comprueba también si el cambio buscado ocurrió y qué supuestos resultaron falsos.

OKR y Scrum

OKR y Scrum son complementarios: operan a escalas de tiempo diferentes y responden a preguntas distintas.

  • OKR responde a "¿en qué dirección estratégica trabajamos este trimestre y cómo sabremos si avanzamos?". Opera a escala trimestral o anual.
  • Scrum responde a "¿qué construimos en las próximas semanas para avanzar en esa dirección?". Opera a escala de sprint.

La pila del producto sirve de puente: las historias de usuario que entran en la pila deberían poder vincularse con algún KR. Si una historia no puede conectarse con ningún resultado clave del trimestre, merece una conversación sobre su prioridad.

El propietario del producto usa los OKRs para priorizar el backlog y para resistir peticiones de funcionalidades que no contribuyen a ningún resultado clave acordado.

Trampas habituales

Feature factory

Una organización opera como "feature factory" cuando mide el éxito por la velocidad y el volumen de entrega, no por el impacto generado. Los síntomas: KRs que miden porcentaje de completitud de tareas, roadmaps definidos por fechas de entrega sin métricas de éxito, y equipos que celebran despliegues sin validar si algo ha cambiado para los usuarios.

Sandbagging

El sandbagging ocurre cuando los equipos proponen metas deliberadamente fáciles para asegurar que las van a cumplir. Aparece especialmente cuando los OKRs están ligados a consecuencias negativas por incumplimiento. La solución es separar los OKRs de la compensación individual y crear una cultura donde el aprendizaje negativo sea tan válido como el éxito.

Cascadeo mecánico

El cascadeo de OKRs (de la dirección hacia los equipos) tiene el riesgo de que los equipos acepten objetivos sin verificar si tienen la capacidad, las habilidades o la autoridad para impactarlos. Un equipo que acepta un KR sobre el que no tiene palancas reales está garantizando el fracaso.

La cascada tiene además otros dos defectos: es lenta, porque cada nivel espera a que el de arriba cierre sus OKRs, y convierte los outcomes en outputs a medida que baja, porque una función aislada solo puede entregar su parte del trabajo. La alternativa que gana terreno es el alineamiento bidireccional: los equipos fijan sus OKRs en paralelo a partir de una estrategia compartida, la dirección aporta el contexto y los equipos proponen cómo contribuir desde su conocimiento del usuario, de modo que lo que aprenden retroalimenta la estrategia. Exige transparencia en la estrategia y confianza para que la base influya en la cima; donde falta esa madurez, la cascada reaparece por inercia.

Meterlo todo en los OKRs

Forzar al formato OKR los compromisos con fecha llena el marco de tareas disfrazadas, como «implantar el nuevo proceso para junio». Felipe Castro propone repartir las inversiones en dos cubos según si su outcome se puede medir: lo que tiene un outcome medible se gestiona con OKRs, y lo que no, como una integración exigida por la ley, una migración de infraestructura o una entrega pactada por contrato, se gestiona por fechas, como un proyecto. Una pregunta ayuda a separarlos: ¿el éxito de este trabajo es un cambio que se quiere provocar, o simplemente tenerlo hecho? El cubo de las fechas no es trabajo de segunda, y dónde trazar la frontera exige criterio.

Error frecuente

Redactar Key Results que son listas de tareas. "Entregar el módulo X, lanzar la campaña Y y completar el informe Z" son tres outputs, no tres resultados clave. Los KRs formulados como tareas producen el mismo incentivo perverso que la feature factory: el equipo se enfoca en completar el trabajo, no en generar impacto. Si al final del trimestre se han entregado los tres ítems pero nada ha cambiado para los usuarios, los KRs se marcan como cumplidos y el objetivo real no se ha alcanzado.

Recursos

🏦 OKRs y estrategia de productoSkill Arena · Scrum Manager

Referencias

  • Doerr, John. (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio/Penguin.
  • Grove, Andrew S. (1983). High Output Management. Random House.
  • Wodtke, Christina. Monday commitments and Friday wins, https://cwodtke.com/monday-commitments-and-friday-wins/

Véase también

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.