El rol del Product Owner en la práctica

El Product Owner es un rol muy importante en los proyectos ágiles: Representa nada menos que la voz del cliente. Se asegura de que el equipo conozca la perspectiva del negocio. Gestiona las historias de usuario, las prioriza, y las mantiene en el product backlog. En un proyecto ágil, no es menos importante la figura del “coach” o ScrumMaster, ocupado principalmente en asegurar que se sigue el proceso y evitar impedimentos.

Personalmente, me interesa mucho el papel nos toca a los Project Managers en un proyecto ágil, pero no está claro si debe ser ScrumMaster, Product Owner, una mezcla de ambos, o bien depende del caso concreto. En las referencias más utilizadas no parece haber una opinión consensuada: En este post se comenta que el Project Manager podría ejercer cualquier rol, dependiendo del caso. Este otro va más en la línea de que el Project Manager debe corresponderse con el rol de Product Owner.

Para arrojar luz sobre el tema, lo primero es conocer en detalle qué se supone que debe hacer el Product Owner en la práctica. Con este fin les recomiendo que visiten este famoso vídeo titulado Agile Product Ownership in a Nutshell. También pueden ver esta otra versión del mismo vídeo subtitulada en español: El rol del Product Owner en la práctica.

A continuación pueden leer una transcripción traducida al español.

El rol del Product Owner en la práctica

Hablemos del desarrollo software ágil desde la perspectiva del Product Owner. Tenemos la figura del Product Owner, tiene la visión del producto y está entusiasmado con el producto. No conoce los detalles sobre lo que el producto hará, pero sí sabe por qué estamos haciendo el producto, qué problemas va a resolver y para quién. Habla de ello continuamente. También tenemos a los interesados, las personas que van a usar, soportar o les va a afectar de alguna manera el sistema que se va a desarrollar. La visión del Product Owner es que a ellos les va a encantar el producto, lo van a usar todo el tiempo y hablarán bien del producto a sus amigos.

Las necesidades de los interesados y las ideas del Product Owner se expresan como historias de usuario. Por ejemplo, si esto fuera un sistema de reserva de vuelos, la gente necesitaría buscar un vuelo, y eso quizá podría ser una historia de usuario. Tanto el Product Owner como los interesados tienen muchas ideas, y el Product Owner ayuda a concretarlas como historias de usuario.

Por otra parte, alguien tiene que construir finalmente el sistema, un equipo de desarrollo software (pequeño, cros-funcional, auto-organizado y coubicado). Dado que esto es un equipo ágil, ellos no generan una gran versión para entregar a la finalización, sino que generan versiones para entregar pronto y frecuentemente. En este caso entregan normalmente 4-6 historias a la semana, esta es su capacidad. La capacidad es fácil de medir, simplemente hay que contar el número de historias entregadas a la semana. Algunas historias son grandes y se cuentan doble, otras son pequeñas y se cuentan como mitades, pero en media podemos asumir que entregan 4-6 historias por semana. Algunos prefieren medir puntos de historia, pero en este caso mediremos historias.

Para mantener este ritmo y no saturarse por las pruebas de regresión manuales, el equipo invierte esfuerzo en automatizar pruebas e integración continua. Así, cada historia tiene al menos una prueba automatizada de aceptación, a nivel funcional, y la mayor parte del código tiene muchas pruebas automatizadas unitarias.

El problema es que un montón de interesados están pidiendo todo tipo de cosas, y seguramente no pueden limitarse a 4-6 ideas por semana, sino que hay muchas ideas y muchos deseos, y cada vez que les entregamos algo, tienen incluso más ideas y piden más cosas. Entonces ¿qué pasaría si tratamos de contentarles y hacer todo lo que piden? Que tendríamos saturación. Supongamos que al equipo le entran 10 historias a la semana pero producen 4-6. El equipo entraría en saturación. Esto causaría multitarea, desmotivación y todo tipo de problemas. Finalmente entregarían menos historias y de menor calidad. Es una propuesta de tipo perder-perder. Es como meter más papel a una impresora para que imprima más rápido, o permitir la entrada de más coches en una carretera atascada. Esto simplemente no funciona sino que lo empeora. ¿Qué podemos hacer?

La técnica Scrum o XP para solucionar este problema se llama “el tiempo de ayer”. El equipo dice: “Dado que las semanas anteriores hemos entregado 4-6 historias por semana, ¿qué 4-6 historias podemos construir esta semana?”

El trabajo que debe hacer el Product Owner es determinar “de todas las posibles historias del universo, cuáles 4-6 deberíamos entregar la próxima semana?” La técnica aplicada en la metodología Kanban es limitar el trabajo en curso (Work In Progress -WIP-). Supongamos que el equipo decide que el número óptimo de historias que pueden realizarse simultáneamente es 5. Han aprendido que este número es suficiente para mantener a todos ocupados sin entrar en saturación. Así que deciden que 5 es el límite WIP, y cuando entregan una historia pueden aceptar otra nueva, siempre que no se supere el límite de 5 historias concurrentes. Ambos enfoques funcionan, porque permiten que el equipo tenga suficiente trabajo que hacer, lo entregarán rápido y de manera efectiva.

Un efecto lateral, sin embargo, es que habrá una cola delante del equipo de desarrollo, que en Scrum se denomina “product backlog”. Esta cola debe ser gestionada. Imaginemos que los interesados se mantienen pidiendo 10 historias por semana y el equipo entrega 4-6. Entonces la cola se haría cada vez más grande, y antes de darnos cuenta tendríamos una lista de peticiones de 6 meses y creciendo. Esto significa que, en media, cada historia que entrega el equipo se corresponde con algo que alguien pidió hace 6 meses, ¿esto es ágil?

Sólo hay una forma de controlar la cola de entrada, y es decir “No”. Es la palabra más importante para un Product Owner, y debe practicarla todos los días delante del espejo. Decir “Sí” a una nueva petición de funcionalidad es fácil, especialmente si esto significa añadir algo al backlog. La decisión más importante para un Product Owner es sobre lo que no se debe construir, y sopesar las consecuencias, por eso es un duro trabajo, por supuesto.

El Product Owner decide qué va dentro y qué va fuera del backlog, y también el orden: qué haremos ahora y qué haremos después, y lo larga en el tiempo que tiene que ser esta lista. Es un trabajo duro, pero el Product Owner no lo hace aisladamente, sino en colaboración con el equipo y los interesados.

Para priorizar, el Product Owner debe tener una idea del valor de cada historia, así como su tamaño. Algunas historias tienen una importancia crítica, mientras que otras son relleno. Algunas tardarán unas horas en desarrollarse, mientras que otras pueden tardar meses. ¿Sabe cuál es la correlación entre el valor de una historia y su tamaño? Exactamente, ninguna. Más grande no significa mejor. Imagine cualquier sistema que usted use habitualmente. Seguro que hay al menos una funcionalidad muy simple, pero que usa todos los días, y seguro que también puede pensar en otra funcionalidad muy complicada que sin embargo no le interesa en absoluto.

El valor y el tamaño es lo que permite que el Product Owner priorice de forma inteligente. Puede haber historias más o menos del mismo tamaño, pero de diferente valor, entonces desarrollaremos la más valiosa primero. Cuando tengan el mismo valor pero distinto tamaño, desarrollaremos la más pequeña primero.
Esto parece fácil, pero un momento, ¿cómo sabe el Product Owner el valor o el tamaño de una historia?

Ahora viene la mala noticia: el Product Owner no lo sabe. Es un juego de adivinar. Un juego en que todo el mundo está involucrado. El Product Owner habla continuamente con los interesados para saber el valor, y habla continuamente con el equipo para saber lo que es grande o pequeño, en términos de esfuerzo de implementación. Se usan valores relativos, no absolutos. No sabemos lo que pesa una manzana ni una fresa, pero podemos estar más o menos seguros de que una manzana pesa más o menos cinco veces más que una fresa. Estas comparaciones relativas se pueden usar para priorizar el backlog.

Cuando empezamos un proyecto nuevo, las estimaciones de tamaño y valor no son fiables, pero no importa: el valor principal está en la conversación, más que en los números. Cada vez que el equipo entrega algo a los usuarios finales, aprendemos algo sobre el tamaño y el valor de lo que tenemos pendiente. Por eso la estimación y la priorización es un trabajo continuo. Tratar de tener estimaciones al principio es casi imposible porque es cuando sabemos menos. Así pues, necesitamos la realimentación desde el principio.

Priorizar, sin embargo, no es suficiente. Para entregar pronto y frecuentemente, hay que descomponer las historias en trozos manejables, para que cada historia consuma pocos días de esfuerzo. Queremos una cola en forma de embudo, con historias claras y pequeñas delante y las historias más grandes detrás. Haciendo esta descomposición just-in-time podemos aprovecharnos de la información más actualizada sobre las necesidades de los usuarios.

Todo lo comentado anteriormente: estimar el valor y tamaño de las historias, priorizar, descomponer... A todo esto lo llamamos “acicalado del backlog”. El Product Owner convoca una reunión de “acicalado del backlog” todos los miércoles de 11-12, una hora por semana. El equipo completo suele asistir, y también algunos interesados. La agenda varía un poco, unas veces se enfoca en estimación, a veces en descomponer historias, otras veces en escribir los criterios de aceptación para una historia, etc.

El tema más importante aquí es la comunicación. Cuando preguntamos a un Product Owner qué es lo que lleva al éxito, suele hacer énfasis en la pasión y la comunicación. No es una casualidad que el primer principio del manifiesto ágil es personas e iteraciones sobre procesos y herramientas.

El trabajo del Product Owner no es “alimentar al equipo con cucharadas de historias”, eso es aburrido e ineficaz. En vez de eso, el Product Owner se asegura que todo el mundo entiende la visión, que el equipo está en contacto directo con los interesados y que hay una realimentación inmediata en términos de entregas frecuentes a usuarios reales.

De esta manera, el equipo aprende y toman decisiones por su cuenta, mientras que el Product Owner se concentra en la foto de alto nivel. Ahora veamos algunos compromisos que tienen lugar entre el Product Owner y el equipo. En primer lugar hay un compromisos sobre los los dos distintos tipos de "valor".

Al principio del proyecto, nuestro enemigo es la incertidumbre y el riesgo. Hay riesgos de negocio: ¿Estaremos haciendo lo adecuado? Hay riesgos sociológicos: ¿Será capaz esta organización de hacerlo? Hay riesgos técnicos: ¿Funcionará en la plataforma destino? ¿Escalará? Hay riesgos de tiempo y coste: ¿Podremos terminar el proyecto con un presupuesto y plazo razonables?

El conocimiento puede verse como lo contrario al riesgo. Así, cuando la incertidumbre es alta, el foco debe ponerse en la adquisición del conocimiento. Nos enfocamos en hacer prototipos de interfaz de usuario, o pruebas de concepto tecnológicas (spikes), quizá no muy emocionantes para los clientes, pero aún así valiosas porque reducen el riesgo.


Desde el punto de vista del valor para el cliente, la curva con el tiempo comienza más o menos plana. Cuando se reduce la incertidumbre, nos enfocamos gradualmente cada vez más en el valor para el cliente. Sabemos qué hay que hacer y cómo, así que lo hacemos. Haciendo las historias de más valor primero, la curva crece rápidamente. Y luego la curva se vuelve a aplanar. Ya hemos construido los temas más importantes, y ahora estamos añadiendo los temas secundarios, la guinda del pastel. En cualquier momento, los interesados pueden decidir la finalización, y así el equipo puede asignarse a otro proyecto más valioso, o quizá comenzar una nueva versión del mismo producto. Esto da agilidad al negocio. Cuando hablamos de valor generalmente queremos decir valor de conocimiento más valor para el cliente. Continuamente tenemos que buscar el compromiso entre estos dos.

Otro compromiso es “corto plazo” frente a “largo plazo”. ¿Qué hay que hacer a continuación? ¿Debemos reparar este defecto urgente? ¿desarrollar esta nueva funcionalidad que nos traerá muchos nuevos usuarios? ¿O bien hay que hacer esta actualización compleja de la plataforma, que permitirá desarrollar más rápido en el futuro? Debemos buscar continuamente un equilibrio entre el trabajo reactivo (apagar incendios) y el trabajo proactivo (prevenir incendios).

Esto está relacionado con el equilibrio entre “hacer lo correcto”, “hacerlo correctamente” y “hacerlo rápido”. Idealmente queremos los tres, pero es difícil encontrar el equilibrio.

• Supongamos que queremos “hacer lo correcto” y “hacerlo correctamente”, es decir, intentamos hacer el producto perfecto con la arquitectura perfecta. Si invertimos mucho tiempo podemos perder la ventana de mercado o tener problemas de caja.
• Imaginemos que queremos “hacer lo correcto” y “hacerlo rápido”, por ejemplo: corriendo para convertir el prototipo en un producto usable. Quizá sea genial en el corto plazo, pero es posible que surjan problemas técnicos y nuestra velocidad sea próxima a cero.
• Si queremos “hacerlo correctamente” y “hacerlo rápido”, construyendo una majestuosa catedral en tiempo record, sólo que los usuarios no necesitaban una catedral, sino un altar.

Existe una tensión saludable entre los roles de Scrum: El Product Owner quiere “hacer lo correcto”, el equipo de desarrollo quiere “hacerlo correctamente” y el ScrumMaster o agile coach quiere “hacerlo rápido”:

Merece la pena hacer hincapié en la velocidad, dado que una realimentación de ciclo corto acelera el aprendizaje, y antes sabremos qué es “hacer lo correcto” y cómo “hacerlo correctamente”. Las tres perspectivas son importantes, por lo que hay que encontrar el equilibrio.


Por último, hay un compromiso entre desarrollar nuevos productos y mejorar productos existentes. El término “product backlog” es algo confuso porque implica que sólo hay un producto. La palabra “proyecto” también introduce confusión porque implica que el desarrollo del producto termina. Sin embargo, un producto nunca termina, siempre hay mantenimiento y mejoras que hacer. Pasar un producto de un equipo a otro es caro y arriesgado. El escenario más común es que el equipo continúa manteniendo el producto existente mientras desarrolla el nuevo producto. Es como si no hubiera un “product backlog” sino un “team backlog”: una lista de trabajos que el equipo debe hacer y que puede venir de varios productos, y el Product Owner debe buscar equilibrios en esta lista.

Cuando un interesado pregunte: ¿cuándo estará listo lo mío? o ¿cuánto de lo mío estará listo para Navidad?

El Product Owner es responsable de gestionar las expectativas de los interesados de forma realista. No es difícil hacer pronósticos, lo difícil es hacerlos de manera exacta.

Si medimos la velocidad del equipo, o la velocidad agregada de los equipos, podemos pintar un diagrama de burn-up de historias en el tiempo (o puntos de historia si lo preferimos así). Noten la diferencia, la curva de las historias muestra “output” (lo que producimos) mientras que la curva anterior del valor para el cliente mostraba “outcome” (lo que entregamos). Nuestro objetivo no es producir más, sino entregar más. Tener interesados contentos produciendo menos, es mejor. Menos es más. Ahora, fijémonos en la gráfica de burn-up. Podemos pintar una línea con la tendencia optimista y otra con la pesimista. La brecha entre las dos líneas tiene que ver con la incertidumbre en la velocidad. La velocidad se estabiliza con el tiempo, así que la brecha tenderá a reducirse en futuras predicciones.

Supongamos que el interesado le pregunta al Product Owner: ¿Cuándo estarán terminados estos trabajos? Esta es una pregunta del tipo alcance fijo-plazo variable. El Product Owner puede usar las dos líneas de tendencia para contestar: “Lo más probable será entre primeros de abril y mediados de mayo”:

Supongamos que el interesado le pregunta al Product Owner: ¿Cuánto trabajo se habrá completado en Navidad? Es una pregunta del tipo plazo fijo-alcance variable. Las líneas de tendencia nos dicen que terminaremos como mínimo las historias debajo del punto pesimista, algunas de las historias entre el punto pesimista y el optimista, y ninguna historia por encima del punto optimista:

Finalmente, supongamos que el interesado pregunta: ¿Podemos entregar estas historias para Navidad? Es una pregunta del tipo plazo fijo-alcance fijo. Observando las tendencias, el Product Owner contesta: Lo siento, no es posible. Podemos entregar menos historias en Navidad o bien podríamos entregar todas esas historias en más tiempo. Es generalmente mejor reducir el alcance que extender el tiempo. Si reducimos el alcance primero, todavía hay tiempo de entregar el total de historias más tarde, mientras que si aceptan más plazo pero luego quieren menos historias en menos plazo, esto ya no es posible:

Este tipo de compromisos entre plazo y alcance son fáciles de hacer para el Product Owner si actualiza sus estimaciones cada semana. Lo importante es que usemos datos reales para los pronósticos y que seamos honestos sobre la incertidumbre. Esta es una forma honesta de comunicar con los interesados, y usualmente lo aprecian. Si estamos en una organización donde la honestidad no es apreciada, probablemente tampoco aprecien los métodos ágiles.

Una advertencia: Si el equipo está acumulando problemas de tipo técnico debido a que no prueban y afinan la arquitectura continuamente, es probable que cada vez sean menos veloces, y la curva de burn-up se hará cada vez más plana. Esto hace que las estimaciones sean casi imposibles de realizar para el Product Owner. El equipo es responsable de mantener un ritmo sostenible. El Product Owner debe evitar presionarles para que busquen atajos.

¿Qué pasa si tenemos un proyecto más grande, con varios equipos y varios Product Owners, cada uno con su “product backlog” con su parte del proyecto? En general, el modelo es prácticamente igual. Igualmente necesitamos gestionar la capacidad, comunicacion con los interesados, Product Owners que sepan decir "No", reuniones de acicalado del backlog, realimentación corta, etc. La velocidad es la suma de los “output”, y podemos usarla para hacer estimaciones, o bien podemos hacer estimaciones para cada equipo, si tiene más sentido. En un escenario con varios equipos los Product Owners tienen una responsabilidad adicional: hablar entre ellos. Podemos organizar los equipos y los backlogs para evitar dependencias, pero siempre hay dependencias imposibles de evitar. Así que hace falta una especie de coordinación entre Product Owners, para que se hagan las cosas en el orden óptimo. En los proyectos grandes, existe la figura del Chief Product Owner para mantener sincronizados a los diferentes Product Owners.