ScrumProduct Goal · Estrategia · Scrum Guide3 may 20236 min de lectura

Scrum necesita un evento de planificación de la Meta de Producto.

La Scrum Guide 2020 introdujo la Meta de Producto como el compromiso del Product Backlog, pero no definió cómo se establece ni cuándo. Este gap tiene consecuencias prácticas que los equipos resuelven de distintas maneras.

La Scrum Guide 2020 fue un paso importante hacia Scrum como marco orientado al valor: la introducción de la Meta de Producto, la Meta del Sprint como compromiso del Sprint Backlog y la Definición de Terminado como compromiso del Incremento dieron al marco una capa estratégica que le faltaba. Pero generó un problema que muchos equipos han experimentado en la práctica: ¿cómo se define la Meta de Producto? ¿Cuándo? ¿Con quién?

La respuesta de la Guía es implícita: es responsabilidad del Product Owner. Pero no hay un evento, ni una estructura de conversación, ni un timeboxing asociado a esa actividad.

01 · El problemaEl gap que la Guía no cubre.

Los eventos de Scrum están diseñados para gestionar el ciclo de entrega a nivel de sprint: planificar, ejecutar, revisar y adaptar. Pero la Meta de Producto opera a un nivel de planificación más largo — semanas o meses — que ninguno de los cinco eventos de Scrum cubre directamente.

La consecuencia en la práctica es que la Meta de Producto se define de dos maneras igualmente problemáticas:

  • Como un trámite: El PO escribe una frase genérica que se pone en el tablero y nadie usa como referencia real para la priorización.
  • Como una decisión unilateral: El PO define la meta basándose en inputs de stakeholders, sin involucrar al equipo en la validación de la hipótesis de valor.

En ambos casos, la Meta de Producto pierde su función: ser la estrella polar que orienta las decisiones del equipo durante el período de trabajo hacia esa meta.

02 · La metaQué debería ser una buena Meta de Producto.

Una Meta de Producto bien construida tiene tres características:

  1. Es un estado futuro del producto: Describe dónde quiere estar el producto, no qué features va a tener.
  2. Tiene una hipótesis de valor implícita: Si alcanzamos este estado, crearemos este valor para estos usuarios.
  3. Es alcanzable en un horizonte concreto: Generalmente entre uno y cuatro meses, dependiendo del contexto del producto.

Ejemplo de Meta de Producto débil: "Lanzar el módulo de reporting avanzado." Esto describe un output, no un estado del producto.

Ejemplo de Meta de Producto fuerte: "Los usuarios de nivel enterprise pueden tomar decisiones de negocio basándose en los datos del producto sin necesidad de exportar a Excel." Esto describe un estado y tiene una hipótesis de valor.

03 · SoluciónCómo cubrir el gap con prácticas complementarias.

Dado que la Guía no prescribe un evento, los equipos que quieren gestionar bien la Meta de Producto añaden sus propias prácticas. Las más efectivas:

  • Sprint de planificación de producto: Un sprint dedicado entre metas, donde el equipo revisa el progreso de la meta anterior, analiza datos de usuarios y stakeholders, y co-crea la siguiente meta.
  • Sesión de Product Goal Setting: Una sesión de 2-3 horas facilitada por el Scrum Master, con la participación del equipo completo y los stakeholders clave, para definir la próxima meta usando herramientas como el Product Goal Canvas.
  • OKR Quarterly Planning: Si la organización usa OKRs, el ciclo trimestral de OKRs puede actuar como el evento de planificación estratégica que genera las Metas de Producto para el trimestre.
RecomendaciónLa opción más sencilla para la mayoría de equipos: reservar los primeros dos días después de alcanzar (o cerrar) una Meta de Producto para una sesión de Product Goal Planning antes de iniciar el siguiente ciclo.
La Meta de Producto sin un proceso para definirla es una etiqueta, no una estrategia.
— Reflexión sobre la Scrum Guide 2020