Breve explicación de qué es un PO y lo que un equipo espera de él. Ser PO es una labor muy importante y muchas veces no se elige a la persona adecuada porque el rol no se comprende.

1. Javier Martín de Agar Tirado
Mi product Owner no se implica

2. ¿Quién es el Product Owner?
 Representa al negocio! Es el experto del negocio.
 ¿Por qué estamos aquí? Comparte el problema
con el equipo.
 Es el analista funcional: debe conocer detalle
funcional del proyecto.
 Es el Jefe de Proyecto: no debemos confundir al
SM con el Jefe de Proyecto, si hacemos una
analogía con el mundo PMP realmente es el PO
el que hace esta labor.

3. Representa al negocio
No conozco tu negocio… explícamelo!
• El equipo de desarrollo es experto en Software, pero no saben del
negocio para el que trabajan.
• Un buen PO conseguirá que el equipo haga suyo el problema que el
proyecto intenta resolver.
Yo se de Software, confía en mi!
• Por otro lado, los expertos en software son el equipo, el PO debe
confiar en las soluciones aportadas por el equipo. Recordemos que el
equipo es dueño del Cómo se hace, colaborar entre equipo y PO será
clave para el éxito del proyecto.
• El equipo siempre propondrá soluciones (las mejores) e incluso
alternativas para que el PO elija.
• Un buen PO confía en su equipo y se apoya en él, imponer solo
consigue que el equipo no comparta el problema y por tanto acabe
dando peores resultados.

4. ¿Por qué estamos aquí?
La visión
• Es ideal trabajar con la visión
• La visión es más profunda que el proyecto, hay expectativas que con
la visión no se escaparán
Compartamos el problema!
• Todos somos equipo, juntos debemos llegar a solucionar el problema.
• Trabajar juntos en resolver el problema hará que hagamos equipo.
Nadie es mejor que nadie y todos jugamos nuestro papel y todos
debemos colaborar en la solución.
Problemas bidireccionales
• El equipo también tiene sus propios problemas. Un PO con empatía
ayudará mucho para que el ambiente de trabajo sea el idóneo.

5. Analista funcional
¿Analista?
• El PO debe centrar su preocupación en explicar al equipo de
desarrollo qué hay que hacer.
• Para poder hacerlo deberá reunirse con muchas personas de su
negocio para entender todos los detalles y trabajarlos.
• A veces tendrá que hacer presentaciones o conseguir validaciones
de los entregables que el equipo de desarrollo vaya completando.
Historias de Usuario
• En el mundo ágil se antepone la comunicación verbal por encima
de todo. Un PO debe sacar tiempo para explicar a su equipo la
próxima iteración.
• Si un PO puede escribir las US mejor, no todos lo hacen pero eso
ayuda mucho al éxito del proyecto y libera al SM para otras tareas.

6. Jefe de Proyecto
El SM es el Jefe de Proyecto
• Muchas personas consideran al Scrum Master como el Jefe de Proyecto.
Pero si pensamos en el mundo PMP un Scrum Master apenas realiza
tareas de un Jefe de Proyecto.
• No debe tener escala jerárquica, no funciona con autoridad, no impone,
propone. Su misión es velar porque la metodología funcione.
¿Quién es el Jefe de Proyecto?
• Si existe un Jefe de Proyecto es el Product Owner. Él controla tiempo,
coste y alcance. Debe gestionar las fechas y compartirlas con el equipo y
con los interesados, debe decidir que US entran y cuales no y debe
priorizar.
• Una de las tareas más importante es la gestión de interesados. Los
proyectos ágiles no conviven bien con fechas y las fechas gustan mucho
porque dan sensación de control. Un buen PO explicará a los interesados
el estado del proyecto y cómo se está priorizando, hay que quitar esa
presión al equipo de desarrollo.

7. Conclusiones
 Un buen PO es aquel que dedica el máximo de
su tiempo al equipo.
 Un buen PO será transparente con el equipo y
compartirá todos sus problemas para que lo
ayuden
 Un buen PO se apoyará en su equipo y se dejará
aconsejar, escuchará y tomará decisiones.
 Un buen PO gestionará a los interesados para
conseguir la información que necesita el equipo y
para evitar que la presión inunde el ambiente de
trabajo.
 Cuanto más tiempo invierta un PO en el proyecto