30 cosas que debes saber sobre el Product Owner.

Hace un tiempo, mientras debatía con un compañero de equipo acerca de los roles, artefactos y eventos que existen dentro de Scrum, nos dimos cuenta de que existen muchas dudas sobre el rol del Product Owner.

Como resultado de este debate, he decidido arrojar un poco más de luz sobre este perfil y destacar 30 realidades sobre el rol del Product Owner en Scrum.

Con respecto del Scrum Team

1. El Product Owner es un miembro más del Scrum Team. Quizás la más clara y evidente, pero mejor no dar nada por supuesto.

2. No es lo mismo que un Project Manager tradicional.

3. El Product Owner debe ser una única persona, bajo ningún caso múltiples personas compartirán este rol o el mismo será desempeñado por un comité. Esto nos ayuda no solo a simplificar y eficientar las comunicaciones, sino que a la hora de priorizar el backlog, no se generarán conflictos.

4. No es el responsable del estado de progreso del desarrollo durante el Sprint, de esto es responsable el Development Team.

5. Debe trabajar junto con el Development Team en elaborar un Sprint Goal. Esto se lleva a cabo en la Sprint Planning y es probable que el Product Owner venga con un objetivo de negocio definido pero que deberá ajustarse junto con el Development Team a lo largo del evento.

6. Si trabaja junto con múltiples equipos para un mismo producto, tan solo tendrá un Product Backlog, en ningún caso uno por equipo. Esto ayudará a tener una visión única y global de todo el producto, pudiendo además anticipar dependencias.

Con respecto de los artefactos

7. No puede modificar el Sprint Backlog, ya que esto es un artefacto que pertenece al Development Team.

8. Es el dueño del Product Backlog y, aunque puede delegar las tareas referentes al mismo, debe ser quien finalmente se encargue de responder/dar explicaciones al respecto de las acciones realizadas sobre el mismo. Recordemos que la responsabilidad puede ser compartida mientras que el hecho de dar explicaciones sobre las acciones realizadas reside en este caso en el Product Owner.

9. Tiene que ser quien monitorice y comparta el progreso del Product Backlog.

10. Se encarga de crear, mantener y ordenar el Product Backlog. Puede pedir ayuda al resto del Scrum Team. Por ejemplo, puede pedir al Development Team ayuda para escribir las Historias y el Scrum Master puede echarle una mano en cuanto a mejores técnicas para mantenerlo y ordenarlo.

11. Podrá actualizar el Product Backlog cuando considere. Recordemos que el Product Backlog es un artefacto que está vivo por lo tanto puede cambiar continuamente (tanto como el Product Owner considere).

12. Debe encargarse de que el Product Backlog maximice el valor del producto y represente las necesidades de los stakeholders. Para ello debe fomentar el feedback no solo de los stakeholders, sino del mercado.

13. Puede apoyarse en el Development Team para refinar el Product Backlog. Esta labor es muy importante, pues nos ayuda a anticipar situaciones, a detallar más aquellos PBI que puedan ser abordadas en la siguiente Sprint Planning, identificar dependencias…

14. Debe colaborar con los stakeholders, los grupos de usuarios y los responsables de producto para conseguir que se involucren y extraer ideas que incorporar al Product Backlog.

15. Puede añadir una catalogación por “puntos de valor” a los PBI y ordenarlo en base al valor que aporte cada ítem al producto. Además, debe tener en cuenta las dependencias entre otros productos, ítems del backlog, áreas... para la ordenación del Product Backlog.

16. Puede delegar la escritura de User Stories en el Development Team, pero debe ser él/ella quien dé las explicaciones pertinentes sobre las acciones realizadas en este ámbito y quien las valide.

17. Será el encargado de aclarar los requerimientos del Product Backlog si el Development Team lo necesitase.

18. No es el responsable de realizar las estimaciones de esfuerzo de los ítems del Product Backlog, pero sí puede aportar un mayor detalle sobre la definición de los mismos, ayudando al Development Team a afinar la estimación.

Con respecto de los eventos

19. Debe asistir obligatoriamente a la Sprint Retrospective, ya que esta es la oportunidad perfecta para inspeccionar y crear un plan de mejoras sobre el Scrum Team.

20. Debe convocar a los stakeholders a la Sprint Review.

21. Debe facilitar la Sprint Review y en ella debe (puede contar con la ayuda del resto del Scrum Team):

• Revisar el estado actual del Product Backlog.
• Inspeccionar el incremento de producto.
• Asegurar que los items entregados cumplen con el Definition of Done (DoD).
• Inspeccionar junto con los stakeholders los cambios del mercado y el potencial uso del producto.
• Actualizar el Product Backlog.
• Podría también realizar proyecciones sobre fechas probables de release en base a la velocidad del Development Team.

22. No puede modificar la fecha de inicio o fin de un Sprint. La duración del Sprint es algo que define el Development Team y debe ser fija en el tiempo. El Product Owner no podrá influir en este aspecto.

23. Puede cancelar un Sprint siempre y cuando el Sprint Goal haya quedado obsoleto. Esta situación es extremadamente anormal, pero podría darse el caso.

Con respecto del producto

24. Es el responsable de todo el ciclo de vida del producto.

25. Es el encargado de vigilar el TCO (Total Cost of Ownership) y esto conlleva contemplar todas las inversiones (concepción, desarrollo, operación y mantenimiento) a realizar en el producto

26. Debiera intentar recibir feedback del mercado mediante la liberación frecuente de incrementos de producto. Algo que repetimos constantemente es “inspeccionar y adaptar” y esto es algo que se puede aplicar no solo al método de trabajo, sino al producto.

27. Debe ser quien más sepa sobre el progreso hacia el objetivo de negocio o el lanzamiento (de un incremento) de producto.

28. Decidirá cuando es liberado un incremento de producto a producción. El Equipo de Desarrollo debe de encargarse de que ese incremento cumpla las necesidades para poder ser liberado a producción.

De ámbito general

29. Debe tener capacidad de decisión, de influir en la organización y disponer de tiempo. En muchas ocasiones podemos encontrarnos con que los Product Owner ocupan cargos altos en las organizaciones y esto puede tener una doble lectura: la positiva que es que tendrá capacidad para influir en la organización y la negativa que en consecuencia tendrá una agenda complicada y poco tiempo.

30. El Product Owner no elige el quién ni el cómo. Es el Development Team quien realiza las tareas y elige cómo hacerlo, mientras que el Product Owner indica qué (hacer), reflejándolo en el Product Backlog con ítems.