Uno de los elementos que se han introducido en Scrum 2020 ha sido el de Product Goal. Este objetivo trata de ayudarnos con el foco global de nuestro producto, indicándonos hacía dónde queremos viajar con la construcción del mismo. Analizamos sus características principales.
Antes, existía la visión
Cuando aprendí Scrum, me enseñaron el concepto de “visión de Producto”. Esta visión trataba de darnos luz sobre el futuro del mismo. Una visión de producto podría ser algo irrealizable pero que fantaseaba, de alguna manera, con un futuro maravilloso para nuestro producto.
Cuenta la leyenda que, en plena Guerra Fría, el presidente de Estados Unidos John F Kennedy visitó los laboratorios de la NASA. Mientras paseaba por ellos, se encontró con un limpiador y Kenndy le preguntó: “¿A qué te dedicas?”. El limpiador lo miró y le respondió: “¿yo? yo me dedico a llevar el hombre a la luna?”
En el mundo anglosajón se trabaja muchísimo el concepto de Visión de Producto. Fantasear sobre que algo es posible permite a las personas superar sus límites y esforzarse por un propósito común.
También se utiliza el concepto de Visión de Producto para explicar nuestro producto rápidamente. Técnicas como el Elevator Pitch, que consiste en explicar en el tiempo que dura un viaje en ascensor nuestra idea de negocio, sirven para convencer a un posible inversionista y atraerlo a tu idea. En los países latinos tenemos menos trabajados estos conceptos, nos centramos mucho en la tarea y nos cuesta mirar más allá y fantasear con los resultados.
Product Goal
El problema de la Visión de Producto es que suele estar muy alejada de la realidad del equipo. Para poder llegar a algo más tangible que guíe al equipo, se utiliza el concepto de Product Goal. El Product Goal es un objetivo a largo plazo, mayor que un Sprint, usualmente a varios Sprints vista. Este objetivo nos permite saber para qué estamos haciendo Sprints. Cada Sprint es una oportunidad de acercarnos al Product Goal y, de hecho, lo revisaremos en cada Sprint Review con stakeholders.
Debe ser único y el grueso de nuestro trabajo debe estar enfocado en cubrirlo. Podemos realizar tareas de otro tipo, pero sin perder de vista cuál es el objetivo que nos hemos propuesto. Hay equipos que, en su tablero de trabajo, utilizan colores para diferenciar aquellos items relacionados con el Product Goal de aquellos que no lo están. Así, podemos visualizar si estamos acercándonos o haciendo tareas sin un foco claro.
¿Cuándo cambiar el Product Goal?
Se puede revisar y cambiar cuando queramos, ahora bien, solo puede existir uno en cada momento. El cambio puede venir motivado porque ya lo hayamos cumplido o porque hemos encontrado otro foco más relevante. Sea de una forma o de otra, no debemos arrancar otro objetivo sin acabar el actual o, al menos, darlo por cerrado de manera transparente.
No existe una regla explícita sobre cada cuánto se puede cambiar, ahora bien, un equipo que cambia de Product Goal sin llegar a cumplirlo y lo hace con mucha frecuencia parece que tiene un problema grave de foco. Cuidado, si no damos tiempo suficiente a cumplir con un determinado objetivo, ¿cómo sabemos que estamos entregando valor? Los experimentos llevan tiempo para ser validados.
¿Cuándo debemos usarlo?
El Product Goal es desarrollado por el Product Owner ya que, dentro del Producto, sirve para explicar el foco general que queremos seguir. Evitemos un compromiso de fecha, sobre todo si no tuvimos en cuenta al resto del Scrum Team para definirlo. El Scrum Master ayuda en esta definición, es decir, si descubre que el Product Owner tiene problemas para definirlo puede acompañarle.
Cada Sprint debe acercarnos hacia el Product Goal actual que tengamos definido. Por eso, en la Sprint Planning, nos preguntaremos cómo nos acerca el Sprint Goal al Product Goal. Y, durante la Sprint Review, hablaremos sobre cómo nos estamos acercando al Product Goal ¿Lo estamos logrando?
Además, el Product Backlog tiene un compromiso con el Product Goal. Un Product Backlog deja de ser una lista infinita de cosas a hacer, para pasar a ser una lista ordenada que debe buscar acercarnos al Product Goal. De hecho, cada incremento es una piedra en el camino hacia el Product Goal, mientras estudiamos el valor que estamos obteniendo y saber si vamos en el camino adecuado.
¿Cómo construir un Product Goal?
A diferencia de la Visión de Producto, el Product Goal debe ser tangible. Debe proyectar un estado futuro que queremos en nuestro Producto. Por ejemplo, si estamos construyendo un portal inmobiliario, podemos tener el siguiente objetivo:
“Tener un portal que permita anuncios anónimos de casas”
Muchas veces, el Product Goal coincidirá con un MVP (Producto Mínimo Viable) sobre todo cuando desarrollamos un producto nuevo. Otras veces, podrá ser una gran ampliación:
“Construir la zona privada de usuarios en un portal asegurador”
De esta manera, estamos marcando un objetivo, con cierta ambigüedad, e iremos añadiendo funcionalidades en la zona privada hasta que consideremos que ya está desarrollada. Otras veces, podemos tener un objetivo para abrir un nuevo mercado o un nuevo idioma:
“Abrir el portal en Francia”
Mi regla personal es que pensemos en unos seis meses, aunque no es una regla escrita en Scrum, puede servir para que sea ambicioso, pero sin que el Product Goal sea “hacerlo todo”.
Y tú, ¿usas el Product Goal?
