Jump to content

OKR

From Scrum Manager BoK
⏱ 6 min de lectura  ·  📅 Actualizado en 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.

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.

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 (cada 2-3 semanas): revisiones periódicas para actualizar el progreso de los KRs y tomar decisiones. Un check-in no es un reporte de estado: es una conversación sobre qué hacer diferente.
  3. Evaluación final: al cierre del trimestre se puntúa cada KR (habitualmente entre 0 y 1) y se extrae el aprendizaje.

La puntuación no es el objetivo: el aprendizaje es el objetivo. Un KR que se puntúa con 0,3 porque la hipótesis era incorrecta es más valioso que un KR que se puntúa con 1,0 porque era demasiado fácil.

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 (en su evolución al rol de Product Architect) 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.

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 productoGuía didáctica Scrum Manager · febrero 2026

🏦 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.

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.