38 cosas que debes saber sobre el Product Owner

Fuente: lecinephileanonyme.com

Habitualmente existen dudas sobre las tareas que realiza cada uno de los roles que propone el marco Scrum, en este artículo indicaremos algunas de las tareas más importantes vinculadas al rol del Product Owner.

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, ayudándonos además a detectar y anticipar dependencias.

7. Si existe más de un equipo trabajando sobre el mismo producto, el Product Owner será el Product Owner de todos los equipos, recordemos que su ámbito es de producto.

8. Puede trabajar junto con el Development Team para construir o mejorar radiadores de información.

9. Colaborar en la definición del Definition of Done en caso de que la organización no proporcionase uno, o hacer más “exigente” (pero alcanzable) el existente si lo hubiera.

Con respecto de los artefactos

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

11. 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 (accountable) 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.

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

13. 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 de Usuario, o detallar PBIs, y el Scrum Master puede echarle una mano en cuanto a mejores técnicas para mantenerlo y ordenarlo.

14. 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).

15. 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.

16. 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, re-priorizar PBIs…

17. 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.

18. 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.

19. Puede delegar la escritura de Historias de Usuario 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.

20. Será el encargado de aclarar los requerimientos del Product Backlog si el Development Team lo necesitase y para ello podrá apoyarse en los Stakeholders o quien considere oportuno.

21. 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

22. 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, del que es parte.

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

24. 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, visibilizando el trabajo completado y el no completado.
  • 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.

25. 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.

26. 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.

27. Puede facilitar una Retrospectiva, ya que es un miembro más del Scrum Team.

28. Puede asistir a la daily como cualquier otro interesado, pero no participar.

Con respecto del producto

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

30. 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

31. 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.

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

33. 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

34. 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.

35. 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.

36. Colaborar con otros Product Owner de la organización a fin de intercambiar información no solo del ámbito de negocio, sino de buenas prácticas, lecciones aprendidas, técnicas…

37. Seguir incrementando y mejorando sus conocimientos sobre Agile.

38. No tiene porque ser un rol con un conocimiento técnico aunque esto puede hacer que su visión de Estrategia y Producto puedan verse beneficiadas por su conocimiento.

Estas son solo algunas de las tareas más importantes que realiza el rol del Product Owner. No debemos olvidarnos que el trabajo del Product Owner está estrechamente ligado al grado de madurez que tenga tanto el mismo, así como al del resto del Scrum Team, y la organización para la que trabajan.

Leave a reply:

Your email address will not be published.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Sliding Sidebar