El Product Owner (PO) representa la voz del cliente, y es el encargado de maximizar el valor del producto.
Un PO siempre debe mantener una visión dual.
El debe entender y apoyar las necesidades e intereses de todos los Stakeholders.
Comprende las necesidades y el funcionamiento del Development Team
Responsabilidades del Product Owner
Determinar las actividades generales de inicio de un proyecto
Asegurar los recursos financieros del proyecto
Centrarse en la creación de valor y la generación del ROI
Evaluar la viabilidad y garantizar la entrega del producto o servicio
Ayudar en la elección de Scrum Master y de los miembros del Development Team
Explicar los User Story al Development Team
Responsable por la administración del Product Backlog
Definir los criterios de aceptación
Ayuda a crear y a aprobar los User Story
Participar en la Retrospectiva de Sprint y del proyecto
Características de un Product Owner
Conocimiento de negocio
Excelentes habilidades de comunicación
Conocimiento de procesos de Scrum
Habilidades de Negociación
Decisivo
Proactivo
Accesible
Orientado a las metas
Representar al usuario o cliente
Responsabilidad del Product Owner
La Visión
La visión debe comunicar la esencia del futuro producto de una manera concisa y describir un objetivo compartido que proporcione dirección, pero que sea lo suficientemente amplio como para facilitar la creatividad. - Roman Pichler.
La Visión - Una Buena Visión del Producto
Compartido
Todos deben comprarlo.
Estable
Debe mantenerse constante durante el curso del proyecto o lanzamiento.
Claro
Debería ser fácil entender la visión.
Amplio y atractivo
La visión debe proporcionar una guía para el equipo, dejando espacio para la creatividad y las compensaciones.
Conciso
A menudo se captura en una o dos páginas de rotafolios o en una página web wiki.
Una técnica alternativa proviene de Crossing the Chasm por Geoffrey Moore.
Para (cliente objetivo).
Quién (declaración de la necesidad u oportunidad).
El (nombre del producto) es una (categoría de producto).
Eso (beneficio clave, razón de peso para comprar / usar).
A diferencia (alternativa competitiva primaria).
Nuestro producto (declaración de diferenciación primaria).
¿Cómo dar forma a una Visión de Producto?
Técnicas para intentar:
Vision Box.
Elevator Statement.
Press Release.
Magazine Review.
One Pager.
El Product Vision Box
El Product Vision Box, es una técnica muy simple pero poderosa promovida por Jim Highsmith que puede ser utilizada tanto por equipos de proyectos ágiles como tradicionales.
Design-the-Box, ejercicio hipótesis:
El producto se venderá en una caja envuelta contraíble. Tarea: Diseñar el frente y la parte posterior del producto.
Nombre del producto.
Un gráfico.
Tres o cuatro puntos claves en el frente para "vender" el producto.
Una descripción detallada de la función en la parte posterior.
Requisitos de funcionamiento.
Después de un taller de Design-the-Box, se puede hacer lo siguiente:
Construyendo su propia versión de la declaración de visión del producto de Moore. Cree un documento completo de visión de productos de una a tres páginas que podría incluir:
Nombre del producto.
La declaración de la misión.
Una descripción general del perfil del proyecto (alcance, cronograma, costo, defectos) con prioridades.
Imágenes de las “boxes“.
Diríjase a los clientes y a cada una de sus necesidades, medidas de satisfacción del cliente.
Tecnología clave y requisitos operacionales.
Limitaciones críticas del producto (rendimiento, facilidad de uso, volúmenes) e indicadores financieros clave.
Maximize ROI.
Release Plan.
MVP.
MMP.
Product Road Map
El mapa de ruta de un producto le permite al equipo de Scrum capturar los objetivos de las próximas versiones de productos; La visión ahora forma parte de la creación y actualización del mapa de ruta del producto.
Éxito del Product Owner
El Product Owner tiene:
Una visión.
Un plan de negocios.
Una hoja de ruta de lanzamiento.
Una acumulación de productos que entregará lo correcto.
El Product Backlog:
Está ordenado correctamente.
Contiene todo el trabajo (incluidos los problemas técnicos).
Está listo para la planificación del sprint.
Tiene el tamaño adecuado.
Se estima apropiadamente.
Tiene especificaciones habilitantes.
Priorización
El Product Owner es una única persona, no un comité.
El Product Owner podría representar los deseos de un comité en el Product Backlog, pero aquellos que quieran cambiar la prioridad de un elemento de la Lista deben hacerlo a través el Product Owner.
Para que el Product Owner pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones.
Las decisiones del Product Owner se reflejan en el contenido y en la priorización del Product Backlog.
Nadie puede forzar al Development Team a que trabaje con base en un conjunto diferente de requisitos
QUIERES SABER MAS DE SCRUM? APRENDE CON NOSOTROS!