Trabajando como Product Owner

Recientemente he trabajado como Product Owner, (PO) y me gustaría dejar constancia de como se estaba realizando esa tarea, ya que me parece un approach muy bueno para el desarrollo de un producto.

En este caso la empresa tenía un equipo de Producto que eran los que efectuaban el desarrollo del producto (research, entrevistas con usuarios, Design Sprints…) y cuyos stakeholders trasladaban las insights y nuevas necesidades de los usuarios al Storiesonboard.

Era mi misión dividir esas nuevas ideas en formato de User Story juntándolas en Releases, en base al valor aportado (marcado por los OKRs) al backlog en JIRA.

A continuación muestro una imagen del ciclo de desarrollo de US que empleábamos:

Produc Owner Cycle

Este ciclo no tenía porque hacerse completo. Si mientras ha estado en el backlog, se habían descubierto nuevas ideas, la User Story volvía al descubrimiento y al StoryMap. La cuestión era:

Minimizar la cantidad de trabajo no realizado.

Empleábamos:

  • Artefactos: Storiesonboard, JIRA, Trello y Slack.
  • Ceremonias (siempre con timing): Daily por squad y grupal (diaria, 15´), Syncro (una cada 2 semanas, 30-45´), Retros (cada 3-4 semanas, 60´) y Asamblea (cada 2 meses, 2h).

Story mapping

Para realizar storymapping usabamos Storiesonboard.com, un software (de pago) que actúa como una panel donde puedes ir distribuyendo las User Stories (US en adelante) en releases y features, y que permite organizar el crecimiento atómico del producto.

Story mapping

En los cuadrados azules, estaban los OKR de la compañía, en los amarillos las MMFs (siglas de Minimum Markatable Feature, característica mínima comercializable) necesarias para alcanzar esos OKR, descritas como adjetivos. Por último, en blanco, debajo de la columna de cada feature, las US necesarias para alcanzarlas. A la izquierda, en letra azul, se marca en que Release o MVP (Minimum Viable Product, Producto mínimo viable) están esas US.

Lógicamente las MMF que tenían más valor estaban más a la izquierda, así como las US con más valor estaban más arriba. Para organizarlo es necesario que el PO disponga de conocimientos y experiencia en aspectos de negocio.

El JIRA estaba dividido en 3 paneles, uno para cada tipo de usuario que trabajaba con él, enlazando así el trabajo del equipo de desarrollo a los objetivos de negocio, muy importante para conocer el estado de una feature y seguir su trazabilidad.

MMF Board

El primer panel, es el MMF Board que posee 3 columnas «To Do, In progress y Done». Puede haber varias MMF por release, enlazadas entre ellas por una etiqueta de JIRA que indica el nombre de la release.

Cada MMF tiene enlazadas las US necesarias para alcanzarlas, pasando a «In progress» cuando la US ha sido informada. Cuando las US han sido realizadas y aprobadas, la MMF pasa a «Done». Cuando las MMFs de la release se han terminado el producto se lanza al mercado.

Si en algún momento una vez lanzada, durante la 2º release, se decide añadir más US a esa MMF, esta vuelve a «To Do».

Definiendo una MMF

Cada MMF es independiente, y no deberían ser secuenciales entre ellas, aunque a veces lo son. Se componen de 3 partes:

  1. Valor: ¿Por qué es necesaria esa MMF? ¿Dónde aporta valor? Debe ser lo más pequeña posible para la visión que tenemos que hacer.
  2. Contexto: Es una mini-narrativa que ilustra porque tiene valor, pero más genérica que una US. Permite bajar a la tierra la MMF.
  3. Background: Aquí se escribe un poco más escribiendo toda la información que sacamos a Producto de por qué hacemos esto.

User Stories Board

Parte de mi misión como PO era mantener en el JIRA este panel y el MMF Board actualizados. El US Board se dividía en más columnas que el anterior, ya que es más de trabajo y requiere más pasos. Las columnas que disponía eran: «Backlog, Proposed, Accepted, To Do, Doing, Review y Done».

JIRA

Imagen de ejemplos de panel extraída de JIRA.com

La columna de «Backlog» sólo la mira el PO, es su espacio de trabajo, donde están todas las US, trabajadas o sin trabajar. A «Proposed» pasan ya finalizadas y organizadas en base a la prioridad que marca Producto (y no por orden de trabajo).

Es muy importante pasar las US ya ordenadas a «Proposed» con tiempo antes de la Syncro para que el Squad pueda leérselas con tranquilidad y sugerir o preguntar cualquier duda que les genere.

Esa conversación que se genera entre todos es lo que aporta valor a la US.

En la Syncro todo el equipo revisa las US y decide cuales pasa a «Accepted». A partir de ahi, es el equipo quien las mueve, pasando a «To Do, Doing y Review». Cuando llegan a esta última columna, vuelve a ser misión del PO revisar si la US se ha realizado cumpliendo los DoD (Definition of Done) marcados y pasarla a «Done».

Escribiendo una User Story

Escribir una buena US es un arte (y mas sin era en inglés como este caso) ya que emplear el lenguaje correcto es muy importante. Una US está formada por 3 campos:

  1. Valor: ¿Por qué esta US? Resumen en una sola frase
  2. Contexto: Es una historia ilustrativa de una acción. Permite entender de una manera más profunda porque a un usuario necesita esa US.
  3. DoD (Definition of Done): Es una lista que indica que se necesita para que esa historia pueda se comprobada (testeada). Son líneas muy concretas que describen esa acción.

Para mi definir un buen DoD era lo más complicado y eso que con mi backend de Diseño y UX estoy acostumbrada a definir qué se necesita y cómo.

Un DoD debe especificar qué se quiere conseguir, pero no indicar cómo, ya que es el Squad el que tiene los conocimientos técnicos para proponer el mejor resultado.

Una US debe cumplir las siglas del acrónimo INVEST:

Independiente – Negociable – Valueble/Valiosa – Estimable – Small (Atomizable) – Testeable

Es independiente, de la forma que si para hacer A necesitas B, si B no existe te fabricas C para poder hacer A. No debe tener dependencias a futuro.

Una US es el inicio de una conversación y cuando hablamos, no imponemos sino que comentamos las cosas, las negociamos. Y para que algo sea negociable debe entenderse y estar definida por si misma. Si algún aspecto plantea dudas es en esa conversación donde se acaba de definir.

La mejor US es la que saca el grano más pequeño aportando valor.

Es estimable, porque en el DoD debe estar lo suficientemente definida para que se pueda medir por parte del equipo de desarrollo, siendo DoDs testeables que se puedan comprobar antes de sacar a producción.

Issues y bugs

A veces aparecen Issues que son otras tareas que no son US, sino modificaciones o añadidos a las US para mejorar. Una Issue tambien puede ser creada por el desarrollador, y será el squad quien la marcará como Bug.

Trazabilidad

Las US se enlazan entre ellas mediante las opciones que ofrece el JIRA:

  • Causes…
  • Related by…
  • Is blocked by…
  • ….

Esto permite tener un control total sobre el producto desarrollado, pudiendo conocer toda su historia. Es perfecto tanto para miembros que han trabajado y necesitan revisar algo, como para el onboarding de las nuevas incorporaciones.

Technical Board

Este es el panel de trabajo del Squad. Son los desarrolladores quienes lo manejan, creando después de cada Syncro las tareas técnicas asociadas a cada US, las Issues, los concerns, aprobando los bugs…

Cada tarea técnica, se enlaza con la US que le corresponde.

De esta manera es como se enlazan los 3 niveles de trabajo.

Pudiendo llegar de la tarea técnica a la MMF y OKR que la necesita.

A mi esta forma de trabajar me parece perfecta para que desde Negocio puedan tener un control total del estado de desarrollo de producto. Además al quedar todo por escrito, la documentación se genera sola, a la vez que aporta valor, estando en una única herramienta (JIRA) y siendo visible para todo el mundo.

¿Tu que opinas? ¿Se trabaja de forma similar en tu empresa?

Trabajando como Product Owner

Un comentario en «Trabajando como Product Owner»

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll hacia arriba