Qué es un Product Owner

El Product Owner es el encargado de añadir valor al producto. Aunque su nombre se traduzca como “dueño del producto” en realidad no tiene por qué ser así. El Product Owner es la persona más implicada con el proyecto, o mejor dicho, con la correcta realización del proyecto. Lo óptimo es contar con el propio cliente pero muchas veces no puede ser así. A veces no tiene tiempo y otras veces no lo ve necesario. En el peor de los casos no se implica lo suficiente, con lo que el resultado es frustrante para todos: si el Product Owner no colabora (en realidad cualquier actor de Scrum), todo se paraliza.

Decíamos que el Product Owner no tiene que ser el que paga por el producto. En ocasiones es incluso una persona del equipo de desarrollo, y aunque no es lo deseable, para proyectos simples o muy manidos es una solución al peor de los males descritos. Lo verdaderamente importante del Product Owner es que tenga una visión clara del proyecto, no solo interna (cómo funciona, cómo son los ritmos, etc), sino externa (cuáles son las fortalezas y carencias del sector al que va dirigido el proyecto, las oportunidades que ofrece, etc). En definitiva, el Product Owner se encarga de añadir valor al proyecto.

Funciones y características de un dueño de producto

Idealmente el dueño del producto debería ser una persona abierta al cambio, comunicativa, activa en el desarrollo, comprometida con todos los actores de Scrum y estar disponible frecuentemente para aclarar las dudas del equipo de desarrollo. La función principal del Product Owner es la de añadir al Backlog del proyecto aquellos requerimientos que supongan un incremento del valor del producto. Únicamente el Product Owner puede añadir y eliminar tareas al Backlog, asignándoles distintas prioridades y especificando cuándo se considera completa.

El dueño del producto debe además poseer unas buenas dotes comunicativas. Si quieres que el equipo de desarrollo junto con el Scrum Master hagan lo que quieres, será mejor que sepas comunicarlo adecuadamente. Pero no solo se comunicará con el equipo de desarrollo, el Product Owner va a tener muchos canales abiertos, y en cada uno va a existir una persona interesada en que se satisfagan sus necesidades en la siguiente versión. Por eso, es importante comprender que el Product Owner no es alguien que paga por el desarrollo, sino la persona que tiene la visión global y de futuro de todo el producto. Obtiene información de muchas fuentes, pero en última instancia es él o ella quien decide qué se debe implementar y qué no, en definitiva, qué aporta valor al producto.

Interacción del dueño de producto con el equipo

Hablábamos anteriormente de la necesidad de contar con un Product Owner con buenas dotes comunicativas. Esto se hace indispensable cuando interactúa con el equipo. El Product Owner es el encargado de decir qué quiere al equipo y dependerá de esa buena comunicación la realización más o menos fiel del proyecto que imagina. La comunicación se efectúa a través del Backlog. A mayor concreción de lo que se pretende conseguir en el Backlog, menos debería ser el uso de otros tipos de canales, que pueden ralentizar el flujo de desarrollo. Solamente el Product Owner es capaz de añadir, y eliminar requerimientos del Backlog, pero no puede obligar al equipo a efectuar un numero determinado de tareas en cada sprint. Serán otros factores los que determinen esto último.

El Product Owner debe velar porque todo el equipo comprender qué es lo que quiere y en ningún momento actuar como un “jefe” imponiendo sus ritmos o la forma en la que se implementan sus ideas. Debe ser el equipo el que encuentre las soluciones a los distintos problemas o requerimientos del cliente, pues el Product Owner debe entender que ellos son los profesionales y quienes tienen más experiencia en el campo. El Product Owner es el encargado de guiar todo el proceso hacia la idea que tiene en mente.

Interacción del dueño de producto con el Scrum Master

El punto de encuentro entre estos dos actores es el Backlog, pero ambos lo usan de forma distinta. Mientras que para el Product Owner es el tablero sobre el que pone las ideas para añadir valor al producto, el Scrum Master es el encargado de velar por la integridad del equipo. Esto no quiere decir que deba existir un conflicto. Este punto de encuentro puede ser muy enriquecedor para ambas partes. Por un lado, el Product Owner puede reinterpretar ciertas tareas para aprovechar al máximo las capacidades del equipo cuyo máximo conocimiento está en manos del Scrum Master y por otro, el Scrum Master puede tener una idea mucho más cercana de lo que se pretende para comunicársela al equipo. La sinergia entre estos dos roles deriva muchas veces en una motivación mayor en el equipo, pues se concretan mucho más los objetivos y se hacen más realistas.

El Scrum Master actúa además como un intermediario entre el equipo y el Product Owner. Aunque el Product Owner se comunica indirectamente con el equipo a través del Backlog, éste puede transmitirle sus preocupaciones o ideas al equipo a través del Scrum Master, que a su vez podrá hacer lo propio con el Product Owner.

El dueño de producto en el Scrum diario

Como todos los miembros del equipo el Product Owner está invitado a participar en el Scrum diario para conocer cómo se está desarrollando el proyecto. Es recomendable su asistencia porque pueden existir malinterpretaciones de las tareas existentes en el Backlog y es útil detectar estas a tiempo, pues de otra forma se habrá perdido un tiempo valioso.

Durante el Scrum diario, el Product Owner deberá dejar el protagonismo a los demás miembros del equipo limitándose a aclarar las dudas que existan. Bajo ningún concepto debe guiar el flujo de trabajo, añadir tareas que no estaban en el Backlog o pisar el terreno de otros roles. Por mucho que tenga conocimiento de la tarea que se esté realizando, no debe imponer su criterio sobre el equipo de desarrollo, ya que lo que busca la metodología Scrum es el aprendizaje mediante el fallo al final de cada ciclo y estas actitudes aunque pueden prevenir el error, hacen al equipo dependiente e impide que madure.

El dueño de producto durante la planificación del Sprint

La planificación del Sprint es un ritual de vital importancia para el Product Owner. Al ser la única persona con conocimiento profundo del producto y el único que es capaz de modificar el Backlog, se hace indispensable su presencia en la planificación del sprint. Para ello, debe priorizar las tareas que hay en el Backlog, así como asignar las dependencias entre ellas con el objetivo de no introducir el sprint tareas que no se pueden llevar a cabo sin la inclusión de otras.

Es necesario que se cercione de que las tareas son claras, entendibles y tienen un punto de finalización o un objetivo concreto y mesurable. Durante este proceso el Product Owner debe ser capaz de transmitir la importancia de las tareas que pretende llevar al sprint para hacer partícipe al equipo de la necesidad de su correcta realización y el impacto que tendrán en el producto que se está desarrollando. Una vez explicadas las tareas, hay que fijar los objetivos del sprint. Este objetivo pueden ser varios, una mejora de la experiencia del usuario, una funcionalidad y en resumen, cualquier añadido que el Product Owner considere que agrega valor al producto.

Una vez el Product Owner haya explicado cual pretende ser su meta para el sprint, la reunión girará en torno a la negociación para la creación del Backlog del sprint. En este momento, el Product Owner debe respetar las impresiones del resto del equipo, ya que los recursos, conocimientos y tiempos para el sprint no son infinitos y una sobrecarga del Backlog del sprint puede evitar que se llegue a buen término el ciclo de Scum. Por tanto, la ultima palabra sobre lo que se añade o no a la pila de tareas del sprint la tiene el equipo.

Debe mantener en todo momento un ambiente estimulante e intentar que el equipo se esfuerce al máximo pero sin llevarlo más allá del límite. Para ello, el Scrum Master intentará llegar a un consenso entre ambos actores, pues es quien tiene el conocimiento y la impresión global más experta de las virtudes y carencias del equipo.

El dueño de producto durante la revisión del Sprint

Durante la revisión del sprint todos los actores se reúnen para ver y probar todos los avances que se han realizado durante el sprint. El Product Owner tiene que guiar la reunión, revisando una por una todas las tareas introducidas en el sprint y pidiendo al equipo que le demuestre que se han completado. Aquí es donde cobra especial relevancia la clarificación del objetivo de cada tarea y que sea cuantificable. En el caso de que una tarea haya cumplido con todos los requisitos de finalización se considerará terminada y en el caso de que no haya podido ser así, tendrá que actualizarse si así lo considera el Product Owner para futuros sprints.

Una vez exploradas las nuevas funcionalidades del producto el Product Owner explicará como afectan esos cambios al sprint y cual es la visión a futuro para hacer a todos los integrantes partícipes.

El dueño de producto durante la retrospectiva

Aunque a primera vista no parece que tenga mucho sentido que el dueño del producto aparezca en esta reunión, su presencia no es menospreciable. A pesar de que su intervención en un sprint debe ser mínima, esta reunión puede servirle para enriquecer su conocimiento del equipo, ver sus dificultades e incluso hacer autocrítica. Puede que descubra que algunas tareas que no fueron implementadas correctamente en el sprint y fueron marcadas como incompletas en su revisión, no hayan salido adelante por una falta de clarificación de las mismas en el Backlog, o por diversas dificultades del equipo. Puede que se de cuenta de que algunas funcionalidades que tiene pensadas sean excesivamente complejas para verlas en una versión a corto plazo y eso puede ayudar a planificar mejor las nuevas funcionalidades en función de su prioridad y hacerse una idea más precisa de los tiempos del proyecto.