Blog en construcción

Blog todavía en construcción y en permanente evolución. Vuelve de vez en cuando, porque estoy incorporando nuevos contenidos.

lunes, 19 de julio de 2021

El Product Owner

El Product Owner es uno de los tres roles que se pueden encontrar en Agile.

El Product Owner es el responsable de definir las Historias de Usuario (User Stories) y priorizar el backlog del team. Su papel principal es maximizar el valor producido por el equipo y asegurar que las historias que se crean satisfacen las necesidades del usuario y cumplen la Definición de Hecho (Definition of Done, DoD).

El Product Owner es el punto de contacto entre el cliente y el equipo y debe tener una relación muy estrecha con Product Management y otros stakeholders (incluyendo otros Product Owners), con el objetivo de poder definir y priorizar las historias de usuario en el backlog del equipo.

Veamos algunas de las responsabilidades del Product Owner:

  • Actualizar y mantener el backlog antes de la planificación de las iteraciones. El Product Owner tiene un diálogo constante con los clientes y stakeholders para conocer sus necesidades y las del negocio, y antes de la reunión de planificación de la iteracion, el Product Owner debe actualizar el backlog del equipo incluyendo nuevas historias que hayan aparecido, eliminando otras que ya no tengan sentido (o reduciendo considerablemente su prioridad), y debe actualizar la prioridad de todas ellas según unos criterios concretos. El backlog también incluye mejoras, refactoring, etc. y el Product Owner es el responsable de priorizar todos los elementos, basándose en el valor para el usuario, el tiempo, y posibles dependencias con otros teams o productos.
  • Participar en la planificación de las iteraciones.  Durante el evento de planificación, es el responsable de que las historias de usuario que se van a abordar en la iteración estén claras para el equipo y ayuda a definir el objetivo de la iteración que se está planificando. También es responsable de coordinar las dependencias con otros Product Owners. Durante la planificaciión se encarga de que el equipo esté alineado y lleguen a un acuerdo sobre el objetivo y resultado finales de la iteración.
  • Aceptar las historias. El product Owner trabaja con el equipo para aceptar las historias completadas. Esto incluye validar que dichas historias cumplen los criterios de aceptación (Acceptance Criteria), que incluye los test necesarios para ser aceptada y que cumple con la Definicion de Hecho (Definition of Done) de cada historia. De este modo el Product Owner asegura el nivel de calidad de las entregas del equipo.
  • Participar en la Revisión. El Product Owner colabora con el team y con cualquier otro stakeholder involucrado e interesado en la revisión de los resultados que el equipo entrega en esa iteración.
  • Participar en la Retrospectiva. El Product Owner es un miembro más del equipo a la hora de Inpeccionar y Adaptar, y la retrospectiva es un claro exponente de esta parte del proceso de evolución del team. Durante esta retrospectiva pueden aparecer ideas de mejora del producto y el Product Owner debe estar involucrado en las discusiones para conocer el alcance y el impacto de esas mejoras y de ese modo tener la capacidad de incluirlas en el backlog y priorizarlas.

Si bien en las primeras propuestas de Agile (y Scrum) el Product Owner estaba excluido de las retrospectivas, en recientes versiones del marco de trabajo y de la metodología se le incluye dada su perspectiva y su contribución a mejorar el rendimiento del proceso, el equipo y el producto. En soluciones intermedias lo que se acuerda con el equipo y el propio Product Owner es que este último participa en la ceremonia y cuando falta un rato para concluir se ausenta, para que el equipo tenga total libertad de hacer mención específica de aspectos relacionados directamente con este rol y/o con la persona, manteniendo la confidencialidad de quién o quiénes han emitido los comentarios y opiniones.


El rol del Product Owner es crítico, y normalmente requiere una persona con dedicación completa a un team, o como máximo dos teams.

No hay comentarios:

Publicar un comentario

Algunas diferencias entre Agile y Waterfall

En este post vamos a comentar algunas diferencias entre Agile y Waterfall en tres aspectos relevantes en la gestión de proyectos, los requis...