El Product Owner y el valor del Storytelling

Cuántas veces hemos repetido una y otra vez que las metodologías ágiles ‘van de personas’, y es que hay dos valores del manifesto que resaltan el papel de las personas:

Individuos e interacciones sobre procesos y herramientas
Colaboración con el cliente sobre negociación contractual

Me gusta decir que en el primero se engloba el cliente también. Es una persona, es la persona que va a valorar nuestro producto, por lo que las interacciones con ella son fundamentales así como la manera de transmitir los problemas de esta persona con el producto, las necesidades y futuras oportunidades que podemos ofrecer. Una de las maneras de definir los elementos del Product Backlog son las historias de usuario, donde hoy quiero hacer especial hincapié en la historia.

Descubrir la historia del usuario

Siempre hay un primer momento en el que conocemos una historia de usuario y como Product Owners tomamos nota de ella. A partir de aquí hay una labor de descubrimiento tanto del usuario como de la historia. Según el caso, este descubrimiento puede llevar unos minutos, unas horas e incluso días. En este punto del proceso el Product Owner está involucrado constantemente y puede que algunos miembros del equipo de desarrollo. El caso es que esto dura tanto como sea necesario para tener claridad de cuál es el problema/necesidad que tenemos que resolver, para quién y si nos van los números – que espero que sí – podríamos tener en la cabeza algunos tests y métricas que podríamos considerar para validar si estamos acertado con la propuesta de valor o mejor dicho, aportando valor a la persona a través del producto. Es posible que durante el descubrimiento, hayamos creado un elemento en el Product Backlog e introducido la información relevante de las conversaciones – Card + Conversation al menos. Podemos decir que en este punto, el Product Owner y quienes hayan colaborado en el descubrimiento, tienen un contexto y propósito muy claro respecto la historia de usuario.

Contar la historia del usuario

En Scrum, se habla de un proceso constante de refinamiento de los elementos del Product Backlog:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.

Si nos llevamos este al día a día, significa que habrá ciertos momentos en los que el equipo se junta para revisar los elementos y si se ha añadido uno nuevo, entonces hay que presentarlo. Es aquí donde el Product Owner y el Storytelling juegan un papel fundamental en varios aspectos: poner al equipo en contexto, transmitir conocimiento, crear compromiso.

Poner al equipo en contexto

He visto sesiones en las que se le ha dicho al equipo lo que hay que hacer. Se ha ido al grano, el cliente tiene este problema y vamos a hacer esto, sencillamente, la historia de usuario estaba creada. Esto no es contar una historia, esto no es revisar una historia y esto no es poner en contexto al equipo. Poner en contexto al equipo es contar lo que ha pasado durante el descubrimiento, desde el inicio hasta el fin. Siempre recomiendo tener algo donde dibujar: qué ha pasado y qué pasos hemos dado para crear ese elemento del backlog con la información que ahí está ya descrita. En este momento, el Product Owner debe contar la historia del usuario y el descubrimiento, para que el equipo viva el proceso y todos estemos en el mismo plano.

Transmitir conocimiento

Se aprende mucho en la fase de descubrimiento de una historia de usuario, tanto de la persona como de nuestro producto. Este conocimiento es útil para la historia que estamos elaborando y además para futuras, porque podemos darnos cuenta de otros detalles que debamos explorar. No podemos privar al equipo de desarrollo de esta experiencia, porque ellos son quienes están en los detalles de la implementación y quienes van a validar propuestas de solución o definirlas, sabiendo el coste e implicaciones de desarrollar los tests y posibles soluciones. El Product Owner es responsable de contar la historia, el descubrimiento y las posibilidades que se hayan valorado para que el equipo pueda empezar a entrar en los detalles.

Crear compromiso

No se hacen las cosas igual cuando sientes que pones un grano de arena que cuando ejecutas lo que otro ha pensado. No se hacen las cosas igual cuando tú formas parte de la solución, cuando sientes el problema y lo haces tuyo. El Product Owner cuenta la historia del usuario y el descubrimiento para hacer que el problema sea de todos, y entre todos pongamos una solución. A pesar del nombre de este rol en la guía de Scrum, el producto es de todos, sus problemas, sus errores y sus beneficios, se comparte todo.

Elaborar la historia del usuario

A veces los Product Owner tienen su propuesta, y la tienen muy clara. Esto no debe impedir que el equipo tenga la oportunidad de elaborar las suyas. Cuando yo era Product Owner, muchas veces presentaba mi propuesta al final y durante la sesión de refinamiento dibujaba la conversación, hacía preguntas para guiar y moderar, sólo al final podía comentar mi propuesta si se daba el caso, para evitar que mis ideas se tomaran como un punto de partida o ‘la idea’. El Product Owner debe dejar espacio para que el equipo elabore y añada detalles a la historia de usuario, en verdad las sesiones de refinamiento son donde podemos crear unas interacciones fabulosas para construir el producto en equipo.

Cuando arranca una sesión de refinamiento es cuando se empieza a revisar la historia de usuario, ahora es cuando empezamos a dibujar el problema, dividirlo en piezas, elaborar hipótesis, proponer ideas, definir ventajas y desventajas de cada idea, ahora empieza la conversación en el equipo donde juntos se añaden los detalles, se organiza el trabajo y por tanto, podemos decir que estamos listos para hacer el desarrollo, un desarrollo que hemos definido entre todos – Conversations+Confirmation. En este punto, el Product Owner se encarga de que los elementos del Product Backlog tengan los detalles que el equipo define en la sesión o sesiones de refinamiento – esto no significa que sea la única persona que añada los detalles a la historia en el Product Backlog, por ejemplo alguien del equipo puede ir haciéndolo durante la sesión.

 

Con todo esto, quiero decir que creo, que la manera en la que el Product Owner cuenta la historia, impacta en cómo aprende el equipo, comprende el problema, lo hace suyo y organiza el trabajo a realizar en el producto para entregarle el valor al cliente.

Cuánto más conocimiento transmitimos al equipo, más posibilidades tendremos para satisfacer al cliente.

Os dejo un artículo que leí hace tiempo y cuya estructura puede servir de esqueleto para vuestras futuras historias: Claves para crear Storytelling que impacte.