La guía oficial de Scrum especifica las responsabilidades del Product Owner de la siguiente manera:
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del equipo de Scrum. La forma en que esto se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.
El Product Owner también es responsable de la gestión eficaz de la pila del producto (Product Backlog), que incluye:
● Desarrollar y comunicar explícitamente el Objetivo del Producto;
● Creación y comunicación clara de elementos de trabajo pendiente del producto;
● Pedido de artículos de trabajo pendiente del producto;
● Asegurarse de que el trabajo pendiente del producto sea transparente, visible y comprendido.
Sin embargo, al ser Scrum un marco de trabajo y no una metodología, no explica en la guía cómo los Product Owners pueden hacer estas responsabilidades de manera eficiente, más allá de habilitar los eventos de Scrum y cumplir con sus artefactos. Y es que así como no hay una guía completa para la vida, tampoco para ser Product Owner.
En mi opinión, la guía de Scrum es una invitación a la experimentación, al desaprendizaje y al aprendizaje de otras fuentes.
Experimentación
Hasta que vivimos algo es hasta que podemos absorberlo bien y porque al ser Scrum una propuesta para trabajar a como hemos estado acostumbrados en muchas décadas de métodología tradicional, tenemos que habilitar la cultura de experimentación. Se trata de habilitar la agilidad basándonos en la validación de hipótesis con experimentos breves y medibles que nos ayuden a aumentar el nivel de confianza.
Algo vital de la cultura de experimentación es cultivar la curiosidad y hablando de los Product Owners, esta es una característica muy importante para:
- Ver los fracasos o retrasos como oportunidades de aprendizaje.
- No intimidarse ellos ni intimidar a los equipos a intentar soluciones innovadoras y diferentes.
- Tener una mentalidad orientada a resolver.
Desaprendizaje
Con el paso del tiempo y la mala combinación con la prisa, llegamos a normalizar prácticas ineficientes. Los problemas frecuentes no deberían de ser los mismos durante años. Aparte de prácticas ineficientes, también existe el conocimiento obsoleto. El conocimiento tiene valor en una empresa cuando lo podemos aplicar y nos lleva a resultados de éxito. Las prácticas ineficientes a veces están escritas en políticas y reglas que alguna vez tuvieron que existir debido a ciertas condiciones, pero un día, desaparecen las condiciones y las políticas se quedan solo estorbando y burocratizando.
Como Product Owners es importante quitar las barreras que impidan concebir productos geniales, dentro de esas barreras, hay algunas (lamentablemente) muy frecuentes, por ejemplo, los criterios de decisión. Estos se basan en jerarquía en la empresa y no en beneficios para los usuarios.
No existen criterios de priorización así que todo urge, por lo que todo tiene la misma importancia y termina atendiéndose igual que si no urgiera, solo que tiende a atenderse mal porque los equipos que trabajan con el síndrome de “todo urge”, viven con sobre carga y la sobre carga es una de las enemigas principales de la productividad y la calidad.
Aprendizaje
Una vez que desaprendemos, es decir, identificamos conocimientos obsoletos y prácticas ineficientes que hemos normalizados, abrimos la posibilidad para adquirir nuevos conocimientos. Los Product Owners son parte de varios mundos: El del Análisis de Negocio, el de la Experiencia de Usuario, el de Marketing y el del Negocio. Ser parte de esta intersección es muy enriquecedor cuando se sabe aprovechar, de lo contrario se termina perdido entre tantos conceptos y terminamos perdiendo a los miembros del equipo también.
Los conceptos que más recomiendo aprender para los Product Owners que empiezan en este camino son los siguientes:
- Historias de Usuario
- Esquematización de elementos de trabajo
- Descomposición funcional
- Prototipado como medio de especificación
- Estimación colaborativa
- Talleres de requisitos
- Priorización de elementos de trabajo
- Priorización de elementos de trabajo
- Principios de orientación al usuario
- Técnica de Buyer Persona
- Técnica User Journey
- Técnica de Value Proposition Canvas
El hecho de que la guía oficial de Scrum tenga pocas páginas, no significa que exija poco, solo que no puede ser una guía predictiva, ya que iría en contra de los principios de la agilidad y al final de cuentas, la responsabilidad de evaluarnos para estar concientes sobre la brecha de conocimiento tenemos para poder llevar nuestras funciones con eficiencia, es totalmente nuestra. Y como toda la teoría sin práctica no es nada, te dejo la invitación al nuevo Curso Práctico de Product Owner, el cual es una continuación del Curso de Fundamentos de Product Owner en el que pondremos tus conocimientos a prueba.
¡Nunca pares de aprender y transmitir lo que aprendes!
Curso de Fundamentos de Product Owner
