4.2 - El Product Owner y los eventos

En Scrum, cada evento (ceremonia) está diseñado con un propósito específico para maximizar la transparencia, la colaboración y la eficiencia. El Product Owner, es fundamental para representar la voz del cliente y los intereses del negocio, y desempeña un papel crucial en estos eventos.

Su responsabilidad va más allá de simplemente definir y priorizar el trabajo; es el vínculo esencial que asegura que el equipo esté trabajando en las características más valiosas, alineando la entrega de producto con los objetivos del negocio.

En esta sección, exploraremos en detalle cómo el Product Owner se involucra en cada evento, qué se espera de él y cómo su aporte activo puede influir positivamente en la dinámica y los resultados del equipo Scrum.

El Product Owner en la Planificación del Sprint

• Facilita el evento, asegurando que durante la sesión se discuten 3 temas: ¿por qué este Sprint es valioso?, ¿qué se puede terminar (done) en este Sprint?, ¿cómo se realizará el trabajo elegido?
• Brinda información clara y precisa sobre el trabajo que se pueda terminar este Sprint
• Aclara las dudas en torno a las expectativas de las partes interesadas en el trabajo de este Sprint
• Aclara la información y detalles sobre elementos del Product Backlog.
• Define el Sprint Backlog y el Sprint Goal según la sesión con el equipo durante este evento
• Negocia el alcance del Sprint con los Developers.

Caso práctico: Durante la planificación del sprint, el equipo está indeciso sobre qué funcionalidades priorizar. El Product Owner, Carlos, comparte recientes feedbacks de clientes y argumenta: "Nuestro principal competidor acaba de lanzar una funcionalidad similar, y debemos responder". Desglosa los elementos del Product Backlog, aclarando cualquier duda. Luego, al definir el Sprint Backlog, surge un debate sobre la carga de trabajo. Carlos, con base en la prioridad y la visión del producto, guía al equipo para acordar un Sprint Goal centrado en el impacto y valor para el usuario.

El Product Owner en el Daily

Nota aclaratoria: Si el Product Owner está trabajando activamente en los elementos del Sprint, entonces participa como un Developer, de lo contrario no participa en este evento.

En caso que el Product Owner participe del Daily, es posible que pueda:

• Brindar aclaraciones sobre algún elemento del Product Backlog.
• Recopilar feedback para posibles reajustes del Product Backlog.

Caso práctico: Durante un Daily, el equipo de desarrolladores discute un desafío relacionado con una historia de usuario. No están seguros de cómo implementar una funcionalidad específica. Laura, la Product Owner, quien ocasionalmente asiste a los Dailies, rápidamente comprende la confusión. Después del Daily, aparta a los miembros del equipo involucrados y proporciona una aclaración detallada con ejemplos del comportamiento esperado, resolviendo el desafío. Además, toma nota para mejorar la descripción de historias similares en el futuro.

El Product Owner durante el desarrollo del Sprint

• Agrega elementos al Product Backlog de acuerdo a las prioridades y expectativas de las partes interesadas.
• Realiza el refinamiento y priorización de los elementos del Product Backlog a partir de las sesiones de trabajo con el cliente y/o partes interesadas (esto suele hacerlo en paralelo mientras los Developers estan construyendo el producto).
• Resuelve las dudas a los Developers sobre el trabajo que esta en desarrollo (WIP).
• Colabora con las partes interesadas, identificando necesidades y ajustando expectativas.

Caso práctico: Mientras el equipo está a mitad de camino en el Sprint actual, Tomás, el Product Owner, ya está en conversaciones con un stakeholder sobre las características de un futuro elemento que se desarrollará para el siguiente sprint. Tras obtener un entendimiento claro, programa una reunión de refinamiento con dos Developers para abordar este elemento. Laura, una de las Developers, sugiere una implementación que podría simplificar el trabajo. Tomás ajusta el elemento en el Product Backlog. Cuando llega el momento de la planificación del siguiente sprint, este elemento se discute con mayor fluidez y claridad, gracias a la planificación en paralelo que Tomás llevó a cabo.

El Product Owner en la Revisión del Sprint

• Facilita y dirige la sesión, garantizando un flujo estructurado.
• Asegura que el progreso respecto al Objetivo de Producto sea el foco de discusión de esta sesión.
• Invita y asegura que las partes interesadas clave estén presentes y activamente involucradas.
• Discute el Product Backlog tal y como está.
• Proyecta el objetivo y las fechas de entrega probables basándose en el progreso hasta la fecha (si es necesario).
• Verifica que el incremento cumpla con lo planificado, considerando tanto los criterios de aceptación como la Definición de Terminado (DoD).
• Facilita la discusión sobre posibles mejoras o ajustes en el producto.
• Confirma o redefine prioridades del Product Backlog basándose en la demostración realizada por los Developers, la deuda técnica (si existe) y en las necesidades cambiantes del negocio.
• Aborda la deuda técnica (si existe) y discute su impacto y posibles estrategias para gestionarla o reducirla.
• Indaga sobre las causas de la deuda técnica (para identificar qué aspectos deben mejorarse o ajustarse para la siguiente Planificación del Sprint).

Caso práctico: Durante la revisión del sprint se presenta una funcionalidad de una aplicación de e-commerce. Un stakeholder clave menciona que, aunque la funcionalidad es lo que se pidió, el diseño podría ser más intuitivo para usuarios no técnicos. Laura, la Product Owner facilita el diálogo, para entender mejor la situación y añade esta observación al Product Backlog. Adicionalmente se encuentra un elemento en deuda técnica, por lo que Laura, reajusta el Product Backlog según el feedback recibido.

El Product Owner en la Retrospectiva del Sprint

• Participa en la inspección de cómo fue el último Sprint con respecto a los individuos, las interacciones, los procesos, las herramientas, y la Definición de terminado (DoD).
• Participa de la identificación de lecciones aprendidas, compartiendo perspectivas desde el lado del negocio y el feedback del cliente.
• Participa en identificar las suposiciones erróneas que pudieron desviar al equipo y busca entender la causa raíz, los problemas que encontró el equipo, y cómo esos problemas fueron (o no fueron) resueltos.
• Reconoce y destaca los logros y las áreas de mejora observadas durante el Sprint.
• Puede sugerir la ampliación de la Definición de terminado (DoD) para mejorar la calidad del producto.

Caso práctico: En la retrospectiva, Miguel, el Product Owner, resalta cómo el equipo logró superar un desafío técnico particular durante el Sprint. Sin embargo, surge que algunos Developers sintieron que no se comunicaron suficientemente bien los objetivos de negocio detrás de ciertas tareas. Patricia, una Developer, menciona que esto llevó a algunas decisiones técnicas que, de haber tenido toda la información, habrían sido diferentes. Miguel reconoce esta brecha y propone sesiones breves de alineación antes de cada Sprint para garantizar que el contexto del negocio esté claro. El equipo acuerda intentarlo en el próximo Sprint y evaluar su efectividad en la siguiente retrospectiva.