¿Se permite que el Product Owner esté en el evento Daily Scrum?

Los propietarios de productos son observadores silenciosos en los stand-ups diarios

En la descripción citada, la palabra participar tiene la connotación de "tomar parte activa". El Product Owner debe asistir, pero no debe participar. La reunión diaria está pensada como una reunión de sincronización y coordinación, no como una reunión de estado, y el propietario del producto no tiene un papel activo que desempeñar en ella.

El propietario del producto (PO) puede asistir para escuchar y observar , ya que los procesos de Scrum siempre deben ser transparentes, pero el PO no puede interactuar. Escuchar mientras el equipo planifica el trabajo del día tiene varios propósitos:

• Proporciona a un oyente atento muchos de los mismos beneficios que un pull de estado formal sin ser disruptivo.
• Proporciona al PO una retroalimentación temprana sobre el alcance, que se puede usar fuera del standup para negociar el alcance de las historias de usuario en curso, proporcionar información para el refinamiento de la acumulación o actuar como un "sistema de alerta temprana" de que una terminación anticipada puede ser requerido.
• Proporciona al PO una vista de primera fila de la capacidad diaria del equipo. Esto suele ser útil para establecer expectativas durante la planificación del Sprint y puede proporcionar un conocimiento avanzado de las historias que se deben priorizar en el próximo Sprint.
• Crea un contexto compartido, de modo que cualquier discusión entre el equipo de desarrollo y el propietario del producto a lo largo del Sprint no tenga que comenzar desde cero.

Sí, definitivamente quieres tu PO en el Daily Scrum.

En primer lugar, recuerde que la Guía de Scrum tiene unas 17 páginas y solo cubre las pinceladas más amplias.

El propietario del producto es parte del equipo. Son la conexión directa con el negocio y la persona que firma las historias como terminadas. Absolutamente quiere que el PO esté allí para que sepan lo que está pasando.

En general, se acepta que la intención de la Guía Scrum es que solo los desarrolladores hablen y el PO mantendría preguntas hasta después del standup. La mayoría de los profesores ágiles recomiendan que el PO solo haga preguntas breves durante la reunión para aclarar las cosas. Si una historia está terminada, el PO puede hacer un seguimiento con el miembro del equipo después del Daily Scrum para aprobar la historia, de modo que pueda moverse correctamente a lista.

Curiosamente, Mike Cohn acaba de dar algunos consejos sobre esto en sus cartas de correo electrónico directas a los suscriptores. Recomienda que todos, Scrum Master y Product Owner incluidos, den actualizaciones en Daily Scrum. Es una evolución de nuestro pensamiento que reconoce que hay otro trabajo, más allá de la codificación, que sucede durante un sprint.

Y recuerda, todo es orientación. Si te funciona, esa es la medida más importante de si debes hacerlo.

EDITAR: Estoy en el proceso de obtener la certificación de Entrenadores Certificados de Scrum. Así que estoy explicando esto desde esa perspectiva. La Guía Scrum es un marco. No es prescriptivo, es una guía. También es un concepto en constante evolución. La última vez que se actualizó fue hace más de tres años y Jeff Sutherland, uno de los autores, ciertamente ha seguido evolucionando en sus opiniones.

Entonces, si alguien le dice "No está siguiendo Scrum al pie de la letra", entonces ellos son los que tienen el problema. Un documento de 17 páginas no puede ni pretendía ser el principio y el final de todo.

Los Product Owners deberían estar absolutamente en el Daily Scrum. Cada CST que conozco enseña eso. El papel exacto del PO en el Daily Scrum depende del equipo para decidir en función de lo que sientan que funciona. Recuerde, inspeccione y adapte. No nos mantenemos rígidos, hacemos lo que funciona.

Entonces, si yo fuera su entrenador, le diría que comenzara con el "según el libro", solo hablan los desarrolladores. Luego use sus retrospectivas para decidir si eso funciona.

Un par de notas más: - Jeff Sutherland y Ken Schwaber mantienen la Guía Scrum. Son solo dos voces en la comunidad scrum y no los únicos que estaban allí cuando se inventó.
- El Manifiesto Ágil no es Scrum y son las pautas generales para todos nosotros. Inspeccionar y Adaptar es un principio clave. Al igual que los individuos y las interacciones sobre el proceso y la herramienta.

Obtuve mi certificación CSM hace unas semanas. Una de las dos preguntas que me perdí fue exactamente esta.

La pregunta plantea la razón por la que el PO debe asistir al Daily Scrum (lo que, según Modus Ponens, implica que el PO debe asistir al Daily Scrum).

Respondí que era para garantizar que el equipo de desarrollo aún estuviera en el objetivo de cumplir los objetivos del sprint . Un oyente, como dice CG (+1!).

Me sorprendió saber que la respuesta correcta era ayudar a aclarar los requisitos , lo que implica que el PO tiene un papel activo durante Daily Scrum. Imagínate.

En definitiva, debes ceñirte a lo que dice Joel BC (+1!): haz lo que te funcione .

Creo que la Guía de Scrum considera que el scrum diario es para el equipo de desarrollo, ya que esto los alienta a sincronizar sus actividades durante el sprint. Sin embargo, también se requieren elementos de sincronización entre el equipo de desarrollo y el propietario del producto.

Mike Cohn habla sobre la participación del propietario del producto en el scrum diario para resaltar que es solo otro miembro del equipo Scrum .

Personalmente, diría que tener un Product Owner que solo asista ocasionalmente a un scrum diario no es una buena idea. Estarán continuamente atrasados ​​en los eventos actuales y, por lo tanto, pueden retrasar el scrum diario al hacer preguntas cuyas respuestas el resto del equipo de desarrollo ya conoce.

De manera similar, si un Product Owner asiste al scrum diario y lo trata como una oportunidad para verificar el progreso, tampoco es un uso productivo del tiempo del equipo.

Por otro lado, un Product Owner que asista a cada scrum diario y hable de manera concisa e informativa sería beneficioso para el equipo.

Imagínese si un propietario de producto ha elegido mudarse y está sentado con el equipo de desarrollo. ¿Entonces se negaría a permitirles asistir al scrum diario o hablar en él? No creo que esto envíe un buen mensaje sobre el trabajo conjunto del Equipo Scrum.

La reunión Daily Scrum debe terminar en 15 minutos - máximo 20 minutos. Si el propietario del producto (PO) se une al Scrum diario, daña la autonomía del equipo y, la mayoría de las veces, el PO podría saltar y decir "oye, no hagas esto" o "eso es así" y luego las cosas pueden volverse largas. debates

El PO no debe participar en el Daily Scrum. Deje que los desarrolladores hagan lo mejor que puedan en función de las descripciones de las historias de los usuarios. Si hay algún bloqueador, el Scrum Master tiene que facilitar la discusión y puede llevar el PO al Daily Scrum si es necesario.

Estoy muy del lado de "sí, el PO debería estar en el standup diario". También creo que el SM debería estar allí también. Para el PO, tengo tres razones principales.

1. Pueden lidiar con problemas relacionados con la priorización y la aclaración en ese mismo momento. Esto debe respetar el marco de tiempo, pero si los problemas se pueden resolver en el stand-up es mucho, mucho más eficiente que tener que irse y obtener esa aclaración.
2. El PO puede tener actualizaciones relevantes para el equipo: parte del trabajo del equipo es ayudar al PO a escribir los elementos pendientes. El PO es la voz del cliente, por lo que tenerlos en el stand-up le da al cliente una voz en las reuniones diarias. Y puede hacer las demás ceremonias (refinamiento y planificación).
3. Los hace parte del equipo; interactúan con el equipo regularmente, lo que sirve para generar confianza y comunicación, un factor importante en la creación de equipos buenos y de alto rendimiento.

Sé que la guía de Scrum dice que no deberían estar ahí; pero esta es un área en la que realmente no estoy de acuerdo. Dicho esto, hay buenas razones por las que dicen esto, que son riesgos muy reales que deben tenerse en cuenta. 1. El stand-up es una reunión para el equipo de desarrollo; no es una reunión de actualización de estado para el PO (o SM). En el stand-up, el rol de los PO es apoyar a los desarrolladores en la entrega del sprint. Aprenderán sobre el progreso (y los bloqueadores), pero eso es un subproducto de saber en qué está trabajando el equipo, no el resultado de una actualización de estado. 2. Puede provocar discusiones detalladas, lo que puede hacer que la reunión dure 15 minutos. No me importa tomarme un poco de tiempo en stand-ups para discutir problemas, pero esto también debe ser monitoreado para garantizar que se respete el límite de tiempo y que los problemas se dejen de lado para discusiones posteriores cuando sea necesario. 3. Es más probable que tanto PO como SM dirijan las reuniones diarias: establecer el tono, decidir quién habla, cortar conversaciones que son demasiado detalladas, etc. Esto socava la autogestión. Es muy importante que la OP no asuma este papel; ¡No es su reunión!

Todas estas debilidades son menos probables en un equipo maduro y pueden compensarse con un buen SM que asegure que Standup sirve al Equipo de Desarrollo. Por supuesto, cada equipo y cada entorno es diferente; así que realmente depende del equipo encontrar los patrones de trabajo correctos.