Está en la página 1de 5

Certified Scrum Product Owner (CSPO).

There is no test or exam at the end of the course. The certification includes a two-year
membership with the Scrum Alliance
https://www.scrumalliance.org/certifications/practitioners/cspo-certification
https://www.scrumalliance.org/courses-events/courses/cspo

Professional Scrum Product Owner™ level I (PSPO I)


https://www.scrum.org/professional-scrum-certifications/professional-scrum-product-owner
https://www.scrum.org/professional-scrum-certifications/professional-scrum-product-owner-i-
assessment
https://www.scrum.org/open-assessments/product-owner-open
https://www.scrum.org/courses/professional-scrum-product-owner-training
https://www.scrum.org/courses/professional-scrum-product-owner-madrid-madrid-2018-01-
22-12372
Un Checklist latino para Product Owners
¿Qué tiene que saber, ser y tener un Product Owner para ser "ideal"?

Un Checklist latino para Product Owners


Introducción
Responsabilidades
Habilidades
Técnicas, prácticas, metodologías que debería conocer y manejar
Artefactos / Herramientas
Acerca de este documento

Introducción
Existen varias interpretaciones para el rol "Product Owner" de Scrum, definido de forma
oficial en la Guía de Scrum.

Este "Checklist latino" pretende ser una herramienta útil para que tanto Product Owner's
como Scrum Masters y personas del negocio puedan analizar en qué aspectos están
suficientemente bien y en qué aspectos podrían mejorar, de forma tal de ser cada vez
mejores en su oficio o rol. ¿Cuál es mi norte como Product Owner (PO)?

Existen variaciones del rol de PO en función de diversas circunstancias:


❏ Madurez del equipo en cuanto a su recorrido en agilidad (ver Shu-Ha-Ri).
❏ Tipo de producto (para clientes internos (IT), producto digital masivo (Ej. Trello))
❏ Segmento vertical: games, banking, empresa centrada en producto(s).
❏ Momento dentro del Ciclo de Vida del Producto (no es lo mismo antes de validar
Product/Market fit que durante crecimiento, madurez o declive del producto).
❏ La complejidad del producto (productos muy complejos pueden requerir de un
equipo que cumpla el rol de PO en lugar de una persona).

Responsabilidades
❏ Comprensión: de la necesidad y el valor del negocio. Business skills.
❏ Tener el norte claro: descubrir, clarificar y comunicar la Visión.
❏ Construir, validar (con los interesados), comunicar y actualizar periódicamente el
Roadmap (hoja de ruta, plan de entregas).
❏ Análisis de Información: saber identificar diferentes niveles o jerarquías de
información, categorizar, dividir (hacer slicing), reunir, generalizar, especializar.
❏ Priorización - Decir que no.
❏ Tener foco en el Retorno de Inversión centrado en los objetivos de negocio.
❏ Dar ejemplos concretos que ilustren y permitan entender mejor.
❏ Irradiar información: saber llevar de una manera asertiva la información del
negocio hacia el equipo. Todo el equipo debe tener claro el problema o visión del
producto.
❏ Validación: es responsable de la validación del producto recibido. Commented [1]: Como realiza el PO la validación?
❏ Indagar, preguntar acertadamente (preguntas abiertas o cerradas según debería entonces tener ciertas competencias de una
analista de QA, pues pienso que el PO se coloca el
corresponda en cada momento). sombrero del tester.
❏ Organizar y facilitar las reuniones de Refinamiento del Product Backlog,
Commented [2]: No entiendo qué quiere decir esto.
Planificación del Sprint y Revisión del Sprint. ¿"Producto recibido"? En mi opinión el PO no es
❏ Asistir a la Retrospectiva del Sprint. Dependiendo de la madurez del equipo de responsable de validar el producto, el equipo lo es. Si
es un producto innovador sin product/market fit debe
desarrollo y del equipo de Scrum, a veces se recomienda realizar una Retrospectiva usar técnicas de Lean Startup, HDD, Analytics,
interna para el Equipo de Desarrollo para tratar temas más técnicos y de gestión Prototyping, Design Thinking, UX para que el equipo
propia del equipo y otra reunión de Retrospectiva en la cual participen todos: Scrum transite e itere exitosamente entre Discovery y
Delivery.
Master, Equipo de Desarrollo y Product Owner.
❏ Muy recomendado: Asistir a la Reunión Diaria.
❏ Obtener feedback y dar visibilidad del impacto al cliente en cada iteración.
❏ Mantener el Backlog actualizado (refinamiento adecuado, priorizado).
❏ Fomentar la sinergia entre el Scrum Master y el Equipo de Desarrollo, en pro del
crecimiento en conjunto del Equipo de Scrum.
❏ Si corresponde, coordinarse con los demás Product Owners de un producto o
negocio.
❏ Prestar atención y foco a que las decisiones de diseño (UX - user experience) se
hagan en acuerdo con diseño de la arquitectura.
❏ Constante presencia y colaboración con el equipo de desarrollo. Si es posible, que
trabajen físicamente juntos.
❏ Colaborar en la evolución de la madurez del equipo (ver Tuckman-Lencioni).

Habilidades
❏ Pasión por el problema que estamos queriendo resolver y el descubrimiento del
producto ajustado para resolverlo.
❏ Capacidad de escucha.
❏ Negociación.
❏ Ser un líder y referencia dentro de la organización sobre la visión y el rumbo del
producto.
❏ Comunicación efectiva y eficiente.
❏ Conocer el contexto de negocio (competencia, tendencias).
❏ Empatía con los clientes, el equipo, el scrum master, los interesados, el negocio.
❏ Motivar a que todos los involucrados estén emocionados por construir el producto. Commented [3]: No veo que el PO sea responsable o
❏ Interactuar con toda la comunidad que debe estar presente a la hora de definir deba tener habilidades de motivación. Opino que debe
impulsar activamente a crear un entorno laboral de
detalles y cuestiones macro del producto en construcción. Ejemplos: Product seguridad sicológica que permita la existencia de
Management, Estrategia, Marketing/ventas. equipos autónomos y una cultura de experimentación,
❏ Manejo excelente de su tiempo. sin penalizar el error.

❏ Facilitación. Para situaciones en las cuales se requiere que un grupo de personas


se pongan de acuerdo o lleguen a una definición de prioridades o un detalle de
características.
❏ Buen relacionamiento. Mucho más importante que tener todas las respuestas, es
tener la habilidad de saber “dónde” encontrarlas.

Técnicas, prácticas, metodologías que debería conocer y


manejar
❏ Agile Manifesto: Valores y Principios.
❏ Scrum.
❏ Lean Startup.
❏ Design Thinking.
❏ Agile inception.
❏ User Story Mapping.
❏ Impact Mapping.
❏ Facilitación de espacios participativos.
❏ Definición y división de Historias de Usuario.
❏ Diversas técnicas de Priorización.
❏ Definición de MVP (Producto Mínimo Viable).
❏ Conceptos de Desarrollo ágil, iterativo e incremental de software con el objetivo de ir
descubriendo el valor de negocio.
❏ Elevator Pitch.
❏ HDD (Hypothesis Driven Design / Development).
❏ Realizar experimentos - Canvas de Experimentos.
❏ Métricas/Analytics.
❏ UX (experiencia de usuario).
❏ Prototyping.
❏ Time boxing - Pomodoro.

Artefactos / Herramientas
❏ Story Map.
❏ Product Backlog.
❏ Product Vision Board.
❏ Impact Map.
❏ Kanban board.
❏ Métricas y gráficas de rendimiento.

Acerca de este documento


Este documento fue ideado por integrantes de la Comunidad Latinoamericana de
Metodologías Ágiles.

Quienes participaron en la creación del mismo fueron:


Alejandro Posada (Colombia), Giovanny Cifuentes (Colombia), Guillermo Alvarado
(Colombia), Marcela Barrera, (Colombia), Pablo Tortorella (Argentina), Pablo Lischinsky
(Uruguay), Rox Muñoz (México).

Colaboradores que aportaron con su lectura y comentarios oportunos:


Tommy Christie (Argentina), Roberto Mejías (Chile).

¿Comentarios? Los invitamos a leerlo y agregar sus sugerencias en el documento


compartido:
https://docs.google.com/document/d/1_xa8xZYg3FTGH7ONhMYFIJLu3PDg6ncc9D3XYSIX
BCQ/edit#heading=h.1rh3pipkg4by