Seguro que os suenan preguntas como ¿En cuantos equipos puede estar un Product Owner?.. La forma más sencilla de contestarla es detallar los principales deberes de un Product Owner. Una vez detallados cada persona podrá evaluar, según sus circunstancias, si puede o debe estar en más de un equipo. En este blog ya hemos hablado del product owner o hemos comentado cómo ser un gran product owner. En este post hablaremos de tareas concretas que debe hacer un Product Owner.
Tabla de contenido
Gestionar el Product Backlog
Para poder definir correctamente los ítems del Product Backlog el Product Owner debe conocer las necesidades de los usuarios, no solo las presentes, sino también las futuras. Para ello tendrá que reunirse periódicamente con ellos. Esto le ayudará a aclarar dudas, matices y entender sus necesidades reales, más allá de la pura funcionalidad. Cuando un usuario le requiera realizar un nuevo cálculo el debe preguntarle para que lo necesita.. Esto aportará verdadero valor al producto, más allá de ser un conjunto de funcionalidades. ¿Y si no tiene acceso al usuario? Entonces esta labor se presenta más ardua. Necesitará realizar una investigación de mercado periódica para poder entender así sus necesidades y evolución.
Además tendrá que tener un ojo sobre la competencia. El estudio de la competencia le dará una visión general del mercado. Sin esta visión puede estar perdiendo usuarios que han decidido pasarse a la competencia.
No es suficiente con todo esto. El Product Owner tendrá que conocer hitos o fechas clave dentro del sector que le ayuden a ordenar el Product Backlog. ¿Se acerca un black friday? ¿Existe alguna nueva legislación? ¿Hay una feria el mes que viene donde podría enseñar mi producto?
Solo una vez cuente con toda esta información podrá sentarse delante de su herramienta de gestión del Product Backlog favorita.
Si el product owner carece de esta información se pueden producir cambios repentinos de prioridad durante el Sprint. También es normal que se produzca desperdicio en forma de funcionalidades que no cubren las necesidades reales de los clientes.
Preparar la Sprint Planning
El Product Owner debe preparar la Sprint Planning previamente a que suceda. Para ello tendrá que pensar un objetivo para el siguiente Sprint. Una forma de pensar en este objetivo es hacerse la pregunta: Si un stakeholder me pregunta qué va a tener al finalizar el Sprint ¿Qué le contaría?. Esto obliga a pensar en negocio en lugar de en funcionalidad y también limita el tamaño de ese objetivo. El stakeholder no quiere escuchar una lista de funcionalidades, quiere una frase que le resuma qué va a conseguir al finalizar el Sprint.
Tras esto tendrá que seleccionar los elementos del Product Backlog que una vez realizados hagan que el objetivo se alcance. Esos elementos deben estar lo suficientemente detallados para que el equipo pueda acometerlos. Es probable que anteriormente a la Sprint Planning haya tenido que mantener alguna sesión de refinamiento con el equipo de desarrollo.
Cuando esto no sucede suelen marcarse objetivos difusos o que son una colección de funcionalidades. Además la Sprint Planning suelen ser interminables debido a la falta de trabajo previo en los ítems del product backlog.
Apoyar al equipo durante el Sprint
Durante el Sprint surgirán dudas de negocio o dificultades que impidan completar alguna funcionalidad. En ese caso el Product Owner debe estar presente, el equipo debe saber que puede contar con él.
Esto se traduce en estar a disposición del equipo para aclarar dudas. Además debe ser capaz de renegociar el alcance o llegar a compromisos para conseguir un incremento terminado al final del Sprint. Esto implica que además debe gestionar las expectativas de los stakeholders cuando las cosas se tuerzan. Además en muchas ocasiones el Product Owner será el único que puede desbloquear ciertas situaciones y será su responsabilidad hacerlo.
Cuando el Product Owner no está presente durante el Sprint se suelen producir bloqueos debidos a falta de definición o incluso desarrollar funcionalidades que no cumplen las necesidades de los usuarios. También suelen quedar muchos ítems sin terminar ya que no ha sido posible renegociar su alcance o existen bloqueos que solo el Product Owner puede liberar.
Preparar la Sprint Review
La Sprint Review es mucho más que una demo del equipo de desarrollo a los stakeholder. El Product Owner debe liderar este evento.
El trabajo del Product Owner empieza incluso antes del evento. Debe asegurarse de invitar a los stakeholders adecuados. Una vez iniciado el evento el será el responsable de trasladar si se ha conseguido el objetivo del Sprint y qué funcionalidades están terminadas. También tendrá que informar de las decisiones que ha tomado durante el Sprint. Por último tendrá que presentar los riesgos que ha detectado y una propuesta de cuáles serán las siguientes necesidades a cubrir. Obviamente cuenta con el apoyo de todo el equipo Scrum, lo cual requiere un trabajo conjunto previo al evento.
Además debe asegurarse que exista feedback (aquí tienes un post sobre como podemos dar feedback constructivo con feedback wrap) por parte de los stakeholders, tanto dando su opinión sobre el trabajo presentado, cómo en la detección de nuevas funcionalidades o nuevas prioridades.
Cuando el Product Owner no prepara este evento suele reducirse a una simple demostración por parte del equipo de desarrollo. Además suele recibirse poco, cuando no es nulo, feedback de los stakeholders.
Conclusión
Estas son los principales deberes de un Product Owner aunque seguro que nos dejamos alguno. Con todo esto ¿En cuantos equipos crees que puede estar un Product Owner?
Déjanos tus comentarios más abajo.👇 👇 👇
Entradas relacionadas
Equipo Multifuncional ¿Qué es?4.8 (5)
Comentarios recientes