Definir y usar un Objetivo de Producto: lo bueno y lo malo
Cuando la Guía Scrum de 2020 introdujo el Objetivo de Producto, le dio a la Lista de Producto algo que a menudo le faltaba: una meta única, a más largo plazo, hacia la que trabaja el Equipo Scrum. La Guía describe el Objetivo de Producto como un compromiso de la Lista de Producto: el estado futuro del producto que da a la lista su razón de ser. Un equipo solo puede trabajar en un Objetivo de Producto a la vez, y debería cumplirlo o abandonarlo antes de tomar el siguiente. Para los equipos distribuidos a principios de 2021, apoyarse en una meta escrita compartida importaba más que nunca, porque ya no se podía confiar en la charla de pasillo para mantener a todos apuntando en la misma dirección.
La idea es sencilla, pero es fácil equivocarse. Vale la pena mirar de frente la diferencia entre un Objetivo de Producto que empuja al equipo hacia adelante y uno que son solo palabras al inicio de un documento.
Cómo se ve un buen Objetivo de Producto
Describe un estado futuro significativo del producto: un resultado real para los usuarios o el negocio, no una lista de funciones.
Es singular: el equipo mantiene un solo Objetivo de Producto en foco, para que las prioridades no se fragmenten entre ambiciones rivales.
Cada Sprint puede rastrearse hasta él: el equipo sabe explicar cómo el trabajo del Sprint lo acerca a la meta.
Es lo bastante medible para que el equipo sepa si la ha alcanzado, sin pretender pronosticar la fecha exacta.
Vive en la Lista de Producto, visible para el equipo y los interesados, no enterrado en una presentación de planificación.
Cómo se ve un mal Objetivo de Producto
Es una reformulación de la misión del equipo: demasiado amplia para estar jamás 'terminada', así que nunca enfoca nada.
En realidad son tres o cuatro objetivos grapados juntos, así que el equipo trabaja en silencio en el que más grita esa semana.
Es una lista de funciones disfrazada de objetivo, que dice qué construir pero no qué resultado se persigue.
Nunca cambia y nunca se retira, así que se vuelve un papel tapiz que el equipo deja de leer.
Solo el Product Owner lo ha visto, así que los Desarrolladores no pueden usarlo para decidir compensaciones durante el Sprint.
Cómo usarlo bien
Redacte un solo Objetivo de Producto y hágalo visible. Colóquelo al inicio de la Lista de Producto, donde todos lo consultan, y retómelo en la Planificación del Sprint.
Úselo como filtro en la Planificación del Sprint. La primera pregunta para cualquier trabajo candidato es si acerca al equipo al Objetivo de Producto; eso mantiene coherente la Lista de Sprint.
Deje que el Objetivo de Sprint conduzca a él. Cada Objetivo de Sprint debería ser un paso concreto hacia el Objetivo de Producto, para que ambos se refuercen en lugar de competir.
Retírelo de forma deliberada. Cuando la meta se cumpla, o claramente ya no valga la pena perseguirla, dígalo y fije la siguiente. Una meta que nunca se cierra pierde su sentido.
Un Objetivo de Producto no es papeleo. Bien usado, es el hilo que permite a un Equipo Scrum decir no al trabajo bueno pero fuera de objetivo y sí a las pocas cosas que de verdad hacen avanzar el producto. Redacte uno, manténgalo único, apunte cada Sprint hacia él y retírelo con honestidad cuando llegue su momento.
Si sus equipos practican Scrum pero les cuesta conectar los Sprints diarios con una dirección de producto real, la asesoría en entrega de programas y proyectos de XNM puede ayudar.