Ayudando al Product Owner desde nuestro rol de Scrum Master

Artículo

Ayudando al Product Owner desde nuestro rol de Scrum Master

Como todos en mayor o menor medida sabemos, una de las funciones del Scrum Master es la de ayudar al Product Owner (en adelante PO) en su labor de optimizar y maximizar el valor del producto.

En las organizaciones que comienzan a implantar un marco de trabajo Scrum nos encontramos a personas que adquieren el rol PO pero que no conocen la metodología y no han tenido la oportunidad de ponerla en práctica, más allá de algún curso teórico de iniciación a la misma. En estos casos, la labor del Scrum Master adquiere más importancia si cabe. En mi opinión este no es un trabajo sencillo y rápido, sino que requiere de una estrategia de aprendizaje en primer lugar y que continuará con el empoderamiento del PO y en la que influirán otros factores ligados a la organización en la que nos encontremos.

En este artículo comento varias ideas sobre cómo enfocar la colaboración con POs que no tengan experiencia con metodologías Scrum y cómo ayudarles en la tarea de gestión del Product Backlog, muchas de las cuales hemos puesto en práctica en diferentes equipos Scrum de nuestros clientes.

¿Cómo comenzar nuestra labor en estos casos?

- Conocer a la persona: las primeras reuniones serán vitales para conocer su implicación con este marco de trabajo y su grado de conocimiento del producto. Las habilidades personales del PO también son un factor para tener en cuenta.
Con esta información podremos generar un primer plan de acción inicial en el cual nos aseguraremos de que conoce el porqué de la necesidad de implantar la metodología para el desarrollo de su producto.

- Entablar una relación de confianza plena: el Scrum Master debe saber transmitir al PO que su función es ayudar y facilitar su vida todo lo posible. Con esto el PO entenderá que el Scrum Master no va a adquirir la responsabilidad de construir el producto o definir los objetivos suplantándole, solo ofrecerá técnicas para que él decida qué hacer según su criterio y le ayudará a salvar todos los impedimentos que surjan.

- Iniciar en la teoría Scrum: como Scrum Masters, debemos asegurarnos de que el PO entiende los conceptos clave: pilares y valores, roles y responsabilidades, ceremonias y artefactos Scrum (Product Backlog, Sprint Backlog e Incremento). Como punto de partida el uso de algún ejemplo gráfico para que entienda y empiece a interiorizar estos conceptos es de gran ayuda. En mi experiencia, el ejercicio del dilema del transporte universal sirvió de ayuda para comprender el proceso a seguir.

Product Owner Scrum Master 1

En esta primera fase, nuestra labor es importante para establecer sus responsabilidades, su participación en el proceso y por supuesto también sus límites.

Dados estos pasos iniciales con el PO y en el caso de que sea necesario, con el Dev Team, estaremos en situación de comenzar a trabajar el Product Backlog que será nuestro siguiente gran objetivo.

Ayudando al Product Owner en la generación del Product Backlog con 5 ideas básicas:

1. Para comenzar a trabajar el backlog de nuestro producto, podemos partir familiarizando a nuestro PO con la herramienta de gestión del proyecto que utilicemos. Cuanto antes se familiarice con este tipo de herramientas (JIRA, Azure Boards, Octane) y toda su capacidad, más partido le podrá sacar. La visibilidad del Product Backlog tanto por él como por el equipo de desarrollo es fundamental.

*Consejo: la esquematización a modo resumen de los tipos de elementos que puede añadir al backlog junto con su propósito le proporciona ayuda para identificar qué y cómo añadir elementos a la lista.

Product Owner Scrum Master 2

2. Hacer partícipe al equipo de desarrollo del mantenimiento del Product Backlog. La participación del equipo de desarrollo en las sesiones de refinamiento del backlog ayuda a establecer límites sobre que se puede y que no se puede hacer. Siempre existirán limitaciones tecnológicas que el PO debe conocer.

*Consejo: todo el trabajo realizado por el equipo de desarrollo debe quedar registrado en el Sprint Backlog (a nivel tareas o a nivel subtareas). Esto ayuda a transparentar todos los esfuerzos realizados.

3. Aprender a escribir Historias de Usuario: el proceso de generación de Historias de Usuario y su inclusión en el backlog no es una tarea sencilla. Como todo, lleva su proceso de aprendizaje. El objetivo será construir historias de usuario entendibles por el equipo de desarrollo y que aporten el mayor valor posible al producto. En nuestra labor de Scrum Master ayudaremos a conseguir consensos acerca de lo que debe contener el Definition of Ready y el Definition of Done.

*Consejo: estructurar el contenido de la Historia de Usuario ayudará a ganar experiencia en la creación de estas para continuar en el futuro con otras técnicas.

Product Owner Scrum Master 4

4. Cuanto más pequeño hacemos las cosas en el Product Backlog, más producimos. El PO y por supuesto también el equipo de desarrollo debe ser consciente de que cuánto más definidas estén las historias de usuario, más aportarán a generar valor en nuestro producto.

*Consejo: Si una Historia de Usuario es lo suficientemente compleja como para no poder realizarse en un Sprint, tenemos que ser capaces de dividirla.

5. El Product Backlog no debe ser infinito. El PO tiene que ser consciente de que no tiene sentido que el Product Backlog esté completo. El Backlog debe contener la información y el contenido suficiente como para acometer un próximo sprint y por supuesto debe revisarse y actualizarse siempre que sea conveniente. La posibilidad de priorizar el Backlog ayuda en la generación de valor del producto en el proceso Scrum ya que las prioridades cambian con el tiempo.

*Consejo: Un producto en el cuál esté definido todo lo que hay que hacer no necesita seguir esta metodología de desarrollo.

En este primer artículo aportamos ideas que hemos puesto en práctica y han dado un resultado positivo. Por supuesto, cada Scrum Master tiene sus técnicas favoritas, os animamos a compartirlas con nosotros. En futuros artículos abordaremos como continuar con el empoderamiento del PO con más técnicas y ejemplos.

Conoce a nuestro experto

Artículo de Felipe Cancho, senior de Consultoría Tecnológica de Deloitte