El rol del Product Owner es un rol que ha aparecido en estos años al calor de Scrum. Es una figura interesante y con bastante confusión. El Product Owner es una figura que, desde mi punto de vista, la guía Scrum deja bastante “coja” porque solo dice 5 ideas:
- Gestionar el Backlog
- Hacerlo transparente
- Asegurarse que los items sean claros y visibles
- Gestionar expectativas
- Puede delegar, pero sigue siendo el responsable.
- Una sola persona, aunque puede estar influenciado por un comité.
Ya escribí hace tiempo hablando de que nadie quiere ser Product Owner. Creo que tenemos una idea un poco equivocada de la importancia de esta figura. Jeff Sutherland, en su libro sobre Scrum, hablaba en un capítulo ampliamente de dónde surge esta figura. Él, comentaba, que hay que definir un KPI clave que nos diga si nuestro producto está teniendo éxito, y valorar al Product Owner por su capacidad de hacer que aumente. Por ejemplo, en una iglesia se mide el número de feligreses que acuden o a un policía se le mide por el número de detenciones. Hay que buscar esta métrica y dejar que el Product Owner trate de aumentarla.
Si un Product Owner tiene claro por cómo lo vamos a medir, podrá tomar decisiones con más sentido. Es más fácil parar un cambio de última hora o una tarea no planificada cuando tenemos un objetivo en mente, y podemos argumentando en base a cómo dicha tarea impacta negativamente en nuestro KPI.
El gran problema que se va a encontrar un Product Owner es: ¿Cuál es la expectativa aquí? Porque usar herramientas como Evidence Based Management tiene sentido, pero si el objetivo de lo que hacemos es entregar alcance-en-fecha podemos estar muertos. Si el valor solo es “entregar X features en una fecha”, el papel del Product Owner estará limitado. Si podemos trabajar desde la entrega continua de valor frente a la entrega de una gran cantidad de software en una fecha ganaremos todos por el servicio que prestamos a nuestros Customers.
Otra de las funciones principales de un buen Product Owner es pasar el 50% de su tiempo con los usuarios, con los receptores del software que estamos construyendo. Hay que tener cuidado con el mundo de la consultoría en este aspecto. Nuestro Customer es quien usa lo que construímos, por encima de lo que opina el que nos contrata que puede ser su jefe. Es verdad que esto a veces no es tan sencillo, pero pocos jefes se opondrán a un software que funciona para sus empleados.
La función de gestionar el Product Backlog es quizás, la más importante, la más crítica, y la que más valor puede aportar en una organización. No es solo cuestión de ordenar, es cuestión de medir, de decidir y de gestionar expectativas. Si el equipo se va a centrar en hacer ciertas funcionalidades dejando para más adelante otras, hay que poder gestionar eso y trabajarlo. Muchos Product Owner demandarán estimaciones para poder hablar de fechas, y para eso podemos utilizar el refinamiento. Ser capaz de contentar a todos los stakeholders es una misión casi imposible. Podemos usar la Sprint Review como un ejercicio de transparencia, de expectativas y de demostrar la capacidad del equipo de entregar. ¡Puede ser un arma muy importante para un Product Owner!
¿Con qué criterio priorizamos el backlog? Hay una función que muchas personas obvian de un Product Owner. Se le debe medir por las decisiones que toma. Es decir, por maximizar el valor que es capaz de generar el Development Team. Esto significa que, si por ejemplo, no para de cambiar de criterio a la hora de decidir qué hacer, el equipo perderá foco y la productividad caerá. No podemos en ese caso echar la culpa al proveedor de turno o la consultora, es el propio Product Owner el que debe responder por esto. Si lo tenemos claro, la labor de ordenar el backlog cogerá protagonismo. ¿Debo hacer el elemento A primero o mejor el B? Aquí, un buen consejo es basarte en tres criterios: tamaño del item, valor que creemos que pueda aportar y por último riesgo de hacerlo de no poder completarlo. Basándonos en estos tres criterios, podemos tomar decisiones más correctas sobre la ordenación de nuestro backlog. Y si nos equivocamos, por suerte, tenemos Sprints cortos para poder inspeccionar y adaptar.
Espero que, con este pequeño repaso, hayamos podido aportar algunas pequeñas aclaraciones sobre el papel del Product Owner. ¿Cómo lo véis vosotros?
Tabla de contenido
Entradas relacionadas
Product Mastery, de buen a gran Product Owner0 (0)
Hola,
Gran artículo, claro y al punto. Sobre priorización, busca a @Lezka en twitter, y si estás en Barcelona mira si puedes ir a una de sus charlas sobre priorización Objetiva-Subjetiva, que ayuda una barbaridad a gestionar expectativas, coordinar stakeholders (accionistas) y dirimir rápidamente las necesidades.