Fundamentos de Scrum Framework: Product Owner + Infografía

Este artículo forma parte de una serie en la que revisaremos los fundamentos de Scrum complementados con infografías que los explican. Accede a los otros artículos: Sprint, Planificación, Daily, Review, Retrospectiva

El equipo Scrum es una “unidad cohesionada de profesionales” donde no hay jerarquías o sub-equipos. Sin embargo, hay funciones básicas que deben estar cubiertas adecuadamente, y que en la Guía Scrum se denominan “responsabilidades” (accountabilities) aunque también se conocen como “roles”:

• Construcción del producto con calidad y excelencia por parte de los desarrolladores.
• Optimizar el flujo de trabajo con la aplicación del marco de trabajo Scrum, misión del Scrum Master.
• La maximización del valor del producto entregado, el objetivo del Product Owner.

No es de extrañar que la responsabilidad de Product Owner sea una de las que más se habla. Maximizar el valor de las actividades del equipo implica identificar y caracterizar muy bien las necesidades que hay que solucionar, ordenarlas adecuadamente en el tiempo en función de varios criterios (retorno de inversión, dependencias, restricciones…), determinar si han cumplido las expectativas previstas o introducir los cambios adecuados en cada caso…

El backlog, principal responsabilidad del Product Owner

Para concretar un poco más, la Guía asigna a la o el Product Owner la responsabilidad de gestionar eficazmente el Product Backlog o Pila de Producto. Este artefacto contiene el trabajo pendiente para ampliar y mejorar el producto. Además, debe ser la única fuente de definición del trabajo para el equipo: no debería abordar actividades que no estén recogidas en él.

La herramienta más poderosa del Product Owner es la gestión del backlog: supone la capacidad de definir el QUÉ, y también, la definición del CUÁNDO, ya que el Product Backlog es una lista ordenada. Esto no quiere decir que sea algo que sólo pueda hacerse desde la responsabilidad de PO, agregar elementos al backlog, refinarlos y ordenarlos, es una actividad en la que pueden participar otras personas. Pero la responsabilidad final siempre será del Product Owner.

¿Qué significa “gestionar el backlog”? Según la Guía Scrum implica:

• Desarrollar y comunicar explícitamente el Objetivo del Producto. Recordemos que hay un “Objetivo de Sprint” que se define durante el evento de Planificación y que expresa el valor qué se aportará al producto durante el Sprint. Este Objetivo de Producto es el objetivo a largo plazo del equipo, describe el estado futuro del producto y sirve de guía a la hora de planificar, señalando el destino.
• Crear y comunicar claramente los elementos de trabajo pendientes. Se espera que un o una PO sepa transmitir la visión del producto, sus objetivos, contexto… Por eso se suele decir que el PO lleva “la voz del cliente”.
• Solicitar que se lleven a cabo elementos del producto expresados como PBIs (de Product Backlog Items).
• Asegurarse de que el Product Backlog sea transparente, visible y comprensible.

Las responsabilidades del Product Owner

A través de la gestión del Product Backlog un Product Owner se encarga de definir y modular el trabajo del resto del equipo estableciendo el Qué y el Cuándo.

Contacto frecuente con los Stakeholders

Por ese motivo tiene un contacto muy frecuente con los distintos stakeholders del producto, personas y organizaciones que puedan influir y tener interés en el producto. Como ese interés e influencia puede variar mucho, es responsabilidad del Product Owner entender las necesidades de las distintas partes interesadas y saber darles la relevancia y prioridad más adecuada en cada momento.

Gestión del Product Backlog

Como PO, debe traducir esas necesidades, que son la materia prima de todo el proceso, en algo más refinado y “trabajable” para que se traduzca en elementos del Backlog (PBIs) y pueda ser transformado por los Desarrolladores en algo tangible: el incremento del producto.

Disponibilidad para el equipo

A la hora de refinar las necesidades a elementos de trabajo, un Product Owner puede contar con el apoyo de otras personas, incluso de fuera del equipo. Traducir necesidades, problemas, demandas… en bruto, en unidades de trabajo o PBIs refinados, requiere que el PO sean capaz de “hablar dos idiomas”: el de sus stakeholders y el de su equipo. Cuanto mayor conocimiento tenga de ambos mejor, pero no necesita ser una persona experta desde el punto de vista técnico (para eso ya están los Desarrolladores).

Además, como Product Owner debe atender a las dudas, preguntas y necesidades del resto del equipo. Es mucho más eficiente y efectiva una conversación que evitarla con definiciones completas y extensas.

Una conversación da pie a otras visiones sobre cómo abordar las necesidades de los stakeholders, fomentando la participación activa del equipo y aumentando su compromiso. Por mucho que nos esforcemos, el lenguaje tiende a ser ambiguo e incompleto, y unos requisitos extensos y sobredocumentados generan falsas certezas y seguridad.

Es mejor una visión más simple que fomente el diálogo entre Product Owner y Desarrolladores, lo que explica la popularidad de técnicas como las Historias de Usuario (User Stories o US) para expresar los PBIs.

Por todo ello, el trabajo del Product Owner tiende a ser a tiempo completo: contacto frecuente con los stakeholders, disponibilidad para el equipo y trabajo con el Product Backlog son tareas que complican que se puedan compatibilizar con otras actividades.

Además, las responsabilidades de Product Owner son de una única persona para que sólo haya un criterio a la hora de definir y priorizar el trabajo. Debe ser una persona que forme parte del equipo ya que tener Product Owners alejados o ajenos al equipo, o múltiples son fuente de disfunciones y problemas.

El Product Owner y los eventos

Como parte del equipo Scrum, quien tenga la responsabilidad de Product Owner participa de los distintos eventos del Sprint:

Planificación

Durante la planificación tiene una participación activa y destacada: plantea la primera aproximación del objetivo, aporta el punto de vista del Negocio en representación de los stakeholders, tiene la potestad de priorizar y es con quien negocia el equipo el alcance y plan del Sprint. Es en este momento cuando suele aflorar la tensión natural entre el deseo de entregar más por parte de PO (voz de Negocio) y la realidad de la capacidad del equipo, su contexto, las incógnitas, la historia, o la deuda acumulada en el trabajo.

Revisión

En la revisión o review tiene un papel especial pues debe dar feedback sobre el trabajo realizado junto a los stakeholders que hayan podido asistir. No es la única ocasión en la que dar ese feedback ya que como PO está a disposición del equipo que en cualquier momento puede mostrar el estado del producto y tomar decisiones al respecto.

Retrospectiva

Durante la retrospectiva participa como parte del equipo Scrum y se espera su contribución al proceso de mejora continua del equipo.

Reuniones diarias

Es frecuente debatir sobre si debe asistir o no a las reuniones diarias. Tal y como se define en la Guía Scrum, esta reunión es por y para los desarrolladores, y el PO asiste si compagina su actividad principal con la de participar en el desarrollo. Si no es así, sólo debería asistir bajo invitación: no es un evento para el equipo, es sólo para los Desarrolladores del equipo.

Descargar infografía