En la guía de Scrum hay una sección dedicada a definir el rol del Product Owner donde se dice:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • […]
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • […]

Cuando hablamos del orden de los elementos del Product Backlog solemos usar la palabra priorizar. Siempre encontré dificultades a la hora de priorizar, tanto cuando era Product Owner como ahora trabajando como Programme Manager. Las dificultades se deben a que no es fácil poner en fila de a uno los elementos que maximizan el valor de tu producto, repito, no es fácil. A mi me encantaría poder tener una respuesta única que valga para todos mis Stakeholders cuando me preguntan: “¿por qué esto va antes que eso?”. No hay un truco, no hay una regla mágica, generalmente hay un trabajo de analizar datos, tomar decisiones que implican priorizar y finalmente negociar.

IMG_1060

El valor de analizar

Han pasado un par de años desde que le he dado a los datos la importancia que merecen. Los datos me han ayudado, no sólo a tomar decisiones, sino a reducir la necesidad de ‘convencer’ a otros de dichas decisiones. Para maximizar el valor del producto a través del equipo de desarrollo debes saber, en el contexto de tu producto y empresa, que significado tiene la palabra valor. Considero que hemos de analizar de forma frecuente información que nos llega desde diferentes fuentes: entrevistas a usuarios y clientes, informes donde se plasman nuestros KPIs, estado del mercado y nuestros competidores. En el contexto en el que yo trabajo esta información la generan otros roles, pero está siempre accesible para el Product Owner de manera que pueda hacer uso de ella en las conversaciones con los Stakeholders, con el equipo de desarrollo y consigo mismo, tanto cuando tiene que poner orden en el Product Backlog, como  para incluir información en sus elementos. Considero fundamental que el Product Owner analice los datos para incrementar su conocimiento del producto y tener un criterio para priorizar.

La dificultad de priorizar

Los datos nos ayudan a tener conocimiento, algunas veces nos van a permitir ver claramente por qué deberíamos hacer una cosa antes que otra, pero otras o bien no son concluyentes o no hay datos para tomar una decisión.

Cuando los datos no son concluyentes y/o suficientes, me gusta adoptar el enfoque de las hipótesis. Al final no estamos seguros de que un elemento vaya a aportar valor, pero sí creemos que podría si una serie de eventos ocurren. En este caso el elemento del Product Backlog pretende aprender, confirmar si esos eventos ocurren para tener suficiente información que permita tomar una decisión y priorizar, sencillamente saber si vamos a invertir en algo y en qué orden respecto los otros elementos existentes, o en caso contrario, si no vamos a invertir y debemos eliminar el elemento del Product Backlog. Una aclaración, que no tengamos datos concluyentes, no significa que sólo en estos casos necesitemos aprender. Debemos aprender sobre nuestro producto de forma constante, si añadimos al producto algo que sabemos nuestros clientes quieren, debemos medir el impacto, aprender de su experiencia y seguir iterando.

Existen numerosas técnicas que nos pueden ayudar a priorizar los elementos de nuestro Product Backlog. Personalmente, no hago uso de una única técnica, sino que las uso según el contexto en el que me encuentre. Si bien es cierto, que la primera pregunta que  siempre me hago es: “¿Y si no lo hacemos qué pasa?”, digamos que una de las primeras cosas que siempre evalúo es el “Cost of Delay/Opportunity Loss” porque todo tiene un coste, pero no el mismo. Esto me permite filtrar sobre qué elementos debo analizar antes que otros y así dedicar más tiempo a definir la prioridad adecuada. El Product Owner debe considerar las diferentes fuentes de información para tener una propuesta clara de prioridades y ser capaz, en la medida de lo posible, de explicar por qué debemos realizar una cosa antes que otra evitando que estas justificaciones se basen en una opinión.

 

La capacidad de negociar

The Product Owner is the sole person responsible for managing the Product Backlog.

Es cierto, debe ser una única persona, imaginaros el caos de varias personas cambiando el orden de los elementos, el equipo de desarrollo no tendría una visión clara. Lo que sí es cierto es que el Product Owner no decide sólo las prioridades, hay muchas personas alrededor del producto con sus datos para hablar sobre las prioridades, y aquí la capacidad de negociar del Product Owner es fundamental, por ello hace una labor de analizar datos y definir las prioridades de la mejor manera posible.

Cuando uso la palabra negociar, no me refiero a intentar satisfacer a los Stakeholders, nada de: “venga anda te lo pongo en la siguiente iteración”, no. El Product Owner debe crear un entendimiento común alrededor del producto por encima de las áreas de responsabilidad de cada Stakeholder. Lo mejor para el cliente en cada momento puede ser diferente a lo que el Stakeholder quiere. Cuando surgen estas conversaciones en sesiones dedicadas a revisar prioridades, hay una labor de moderación complicada, pero el trabajo que el Product Owner ha realizado para justificar sus prioridades ayudará a que el debate sea constructivo. Esto no significa que las prioridades que el Product Owner ha puesto sobre la mesa no se puedan tocar, significa que los cambios deben hacerse con criterio y pensando en lo mejor para el cliente. En estas conversaciones pueden surgir cambios de prioridades, convertir elementos del Product Backlog en algo aún más pequeño, simple y de menor alcance que quizá afecte a la prioridad del elemento original e incluso pueden surgir nuevas ideas; no sería la primera vez que alguien sale diciendo: “yo creo que deberíamos hacer…” estos casos es mejor trabajarlos fuera de la sesión, simplemente para separar la revisión de prioridades de la captura de ideas o propuestas. El Product Owner debe tener una capacidad de negociación para moderar sesiones de revisión de prioridades del Product Backlog, es difícil satisfacer a todo el mundo y por eso debe centrarse en lo mejor para el cliente final, el producto junto con datos que lo justifiquen.

En resumen, analizar frecuentemente los datos de su cliente y producto, tener una propuesta clara de prioridades y negociar con criterio el siguiente incremento con los Stakeholders, es clave para garantizar que el equipo desarrolla lo que más valor tiene en cada momento.

Algunas referencias de interés:

10 thoughts

  1. Hola Vanesa, buenos artículos sobre el rol del product owner en Scrum. Inspirado por los tweets de esta semana que surgieron de aquí, he publicado esto. http://blog.jmbeas.es/2018/02/11/roles-vs-jerarquia/

    En resumen, se trata de mi opinión en contra de la idea de que para que un grupo se ponga de acuerdo hace falta una persona con la última responsabilidad. Ya sé lo que dice la guía de Scrum, pero qué sabrán ellos. 😂

    Espero que te guste.

    Le gusta a 1 persona

    1. Hola José,

      me alegra que hayan servido para tu inspiración y sin duda leeré tu artículo. Yo creo que si una conversación de grupo llega al punto en el que una persona X tiene que ‘dar un golpe en la mesa y decir lo que hacer’, hay pasa algo más y la solución no es que exista un único decisor. En mi experiencia he visto al PO como alguien que facilita las tomas de decisiones tras recoger mucho feedback de varios lugares, para facilitar de forma más efectiva, necesita cierta información.

      Cuando lo lea te escribiré mis comentarios, un abrazo.
      Vanesa

      Me gusta

  2. Hola Vanesa.

    Estoy de acuerdo contigo que el PO se base en datos o información válida a la hora de priorizar que construir primero. Es fundamental si no quieres “desperdiciar” los recursos de la empresa.
    Para mí el mayor problema está cuando la organización aún no ha llegado al momento de tener datos disponibles para el PO. Vamos cuando no hay cultura de basar las decisiones en datos. En ese caso la priorización es una mezcla de intuición, experiencia previa y adivinación…
    Como tú, yo tampoco utilizo una técnica concreta. De momento me ha funcionado recoger todo lo que piden los stakeholders (todo es súper urgente y súper crítico por supuesto), junto con el equipo scrum hacer una estimación del esfuerzo que puede suponer, y entonces volver a juntar a los stakeholder y que se maten, perdón, negocien entre ellos que es más prioritario en base a esfuerzo-beneficio para la organización. Creo que es lo mismo que planteas al final del artículo.

    Me gusta

    1. Hola David,

      cuando fui Product Onwer en el pasado no tenía datos como tal para presentar mis prioridades y su por qué. En mi contexto, tenía en cuenta el área de impacto de las peticiones. Ejemplo: yo era la PO del Backoffice de la empresa donde se gestionaban todas las operaciones post-venta de todas las reservas de la página web. Las peticiones relacionadas con pagos y comunicaciones a los clientes solían tener una prioridad alta, después las mejoras en las herramientas las organizaba según el número de veces que se ejecutaba al día esa operativa y cuántos operadores la llevaban a cabo, para tener alguna referencia de en cómo ordenar los elementos del backlog. Digamos que, intenté definir mis criterios con los Stakeholders con la información que teníamos. Definir unos criterios en común, facilitaba mucho las sesiones de revisión de prioridades.

      Un abrazo y gracias por compartir to experiencia,
      Vanesa

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s