Como sabéis en la nueva revisión de la Guía Scrum que se publicó hace unos días, a finales del mes de noviembre, una de las grandes estrellas ha sido la aparición del 'Product Goal'.
En el análisis que publicamos ya hicimos expresa mención al nuevo invitado a la fiesta, el 'Product Goal’', del que decíamos cosas como:
· Se introduce el término "objetivo del producto", 'Product Goal', que sirve para definir un objetivo del mismo y apuntar un estado futuro.
· Otro tema no menos importante, es la aparición estrella del 'Product Goal'. Creo sinceramente que esta adición es más importante de lo que parece. Por un lado, ofrece una tranquilizadora simetría con el 'Sprint Goal', dejando a este último en el terreno de lo táctico y situando al nuevo invitado a la fiesta en la parte estratégica. El disponer de esta nueva meta a nivel de producto facilita el aumento de la transparencia y visibiliza de manera patente qué es lo que se espera del producto, poniendo si cabe aún más foco en las expectativas de este.
· El rol de 'Product Owner' queda impactado por la aparición del 'Product Goal', como no podía ser de otra manera, sobre el que la guía dice que este rol es el encargado, no sólo de "desarrollarlo", sino también de comunicarlo explícitamente.
· La aparición del 'Product Goal', más allá de las virtudes obvias, aporta una simetría que simplifica el marco metodológico.
· El 'Product Goal' es el compromiso asociado al 'Product Backlog' y se presenta como un estado futuro deseado para nuestro producto.
Pues bien, dentro de la propia Guía Scrum, el 'Product Goal' aparece nada más y nada menos que 15 veces mencionado, relacionado con temas tan estructurales como el 'Sprint', el 'Product Owner', el 'Product Backlog', las 'Reviews', el 'Planning', etc. Si esto no es una declaración formal por parte de Jeff y Ken de que este nuevo 'Product Goal' es algo troncal a partir de ahora en Scrum, que venga alguien a rebatirlo.
Pues sinceramente, no tanto. En la guía que evoca la formalidad del marco metodológico, puede que sí lo sea, pero en la realidad, en el día a día de las implementaciones de Scrum, al menos de las que yo tengo algo de información, que no son pocas, quizá no de una manera tan presente como su par, el 'Sprint Goal', pero siempre se ha manejado un equivalente al 'Product Goal' que nos marcara el foco lejano del hacia dónde nos dirigimos con el Producto.
El 'Sprint Goal', su primo cercano, quizá incluso su mejor amigo, es algo de carácter eminentemente táctico. Nos da un foco para no más de un mes de trabajo. El carácter del 'Producto Goal' es más estratégico, algo que nos permite mirar en horizontes de varios meses.
Debe quedar claro que los objetivos de un 'Sprint' y los objetivos de un Producto son compatibles y se complementan entre sí, por lo tanto, el 'Sprint Goal' y el 'Product Goal' lo serán también.
Como os decía anteriormente, la Guía Scrum nos debe servir de referencia en este aspecto, así que vamos a revisar las claves que nos indica al respecto:
1. Con respecto al Scrum Team, la guía es clara, define a este grupo de personas como un equipo focalizado en un objetivo cada vez. Y ese objetivo indica que es el 'Product Goal'.
Indica adicionalmente que, si hay varios equipos trabajando conjuntamente en el mismo Producto, han de estar todos alineados en base al 'Product Goal', y este será el mismo para todos.
2. En relación con el 'Product Owner', incluye entre sus responsabilidades el desarrollar y comunicar explícitamente el 'Product Goal'.
3. Si hablamos del 'Scrum Master', a este rol se le asigna la responsabilidad de encontrar técnicas que ayuden a una efectiva definición y gestión, tanto del 'Product Goal' como del 'Product Backlog'. Implícitamente esto lleva asociado el soporte y tutorización al 'Product Owner' con relación a estos aspectos.
4. El 'Sprint' indica que todos los trabajos que ocurren dentro de él, se realizan en aras de conseguir acercarnos al 'Product Goal' y que es el mecanismo que aporta predicción a través de la adaptación, inspección y transparencia en el foco hacia esa meta.
5. En el evento de planificación, el 'Sprint Planning', habla sobre que el 'Product Owner' se debe encargar de mapear que los PBI escogidos durante la misma y que luego conformarán el 'Sprint Goal', están adecuadamente mapeados con el objetivo que supone el 'Product Goal'.
6. Para el 'Sprint Review' se incluye el informar de cómo lo realizado en el Sprint hace que se avance hacia el 'Product Goal'.
7. Por supuesto, relativo al 'Product Backlog' se incluye el 'Product Goal' como compromiso de este, definiéndolo como el estado futuro al que aspira el producto y que sirve al equipo para realizar sus planes más tácticos. Indica también que este es un objetivo a largo plazo que se debe alcanzar, o abandonar, antes de escoger otro.
8. Por último, con respecto al incremento, lo redefine como un paso concreto hacia la consecución del 'Product Goal', alineando así toda la estrategia a largo plazo del Producto en torno a este nuevo elemento.
Como se puede observar, la estrategia del 'Product Goal' es servir de foco estratégico, a largo plazo, frente al 'Sprint Goal', que lo hace a corto plazo, esto es, un foco táctico.
Cierto es que el elemento introducido formalmente, cierra perfectamente el círculo en torno a la visión de producto como ideación, algo que sin duda faltaba en anteriores revisiones de la guía y que lo hacían de carácter interpretativo para cada equipo. Si bien como decíamos al principio, se usaba, más o menos de manera habitual, no todo el mundo lo utilizaba y generaba debate alrededor de su verdadera necesidad, aduciendo a veces, que su mera existencia, era poco menos que una afrenta a la propia agilidad.
Así, con esta revisión, los creadores de Scrum dejan patente la necesidad de su existencia y que la misma no ataca en forma alguna el carácter ágil del modelo.
En mi opinión, aparentemente compartida por una mayoría de la comunidad ágil, la inclusión del 'Product Goal' no sólo es un acierto, sino capital en la revisión de la guía Scrum de 2020.
Aquellos que no usaban el 'Product Goal', ya sea porque no lo prescribía la guía o bien porque no lo consideraban útil, creo que encontrarán en su incorporación un nivel adicional de foco, a largo plazo, que ayudará a alinear determinados comportamientos erráticos que afectaban a la aparente flexibilidad de la que disponían los equipos y el 'Product Owner' para escoger en cada 'Sprint' lo que considerasen.
En definitiva, un elemento que cuadra perfectamente con lo existente y que ahora que está ahí, parece mentira que no se hubiera incluido antes.
Bienvenido y larga vida al 'Product Goal'.