¿Qué haces si el Product Owner está enfermo?

Pregunta simple. ¿Cómo se ejecuta la revisión de Sprint y la planificación de Sprint?

¿Has oído hablar de los puentes de conferencia?
@WyattBarnett no, ¿qué es?
Llamadas de conferencia. No hay excusa para no hacer una reunión en 2011. A menos que esté en un avión, y eso es un poco tenue.
Si alguien está enfermo, lo más probable es que no participe en una conferencia telefónica.
¿Por qué tengo esta intensa necesidad de decir: "envíale una tarjeta de recuperación o visítalo en el hospital"?
@WyattBarnett, hay momentos en que las personas no están disponibles. Les aseguro que cuando mi compañera de trabajo salió enferma de cáncer no pudo contestar llamadas de trabajo ni participar en conferencias telefónicas. No pude hacerlo cuando murió mi amado. No hay excusa para pensar que las personas son máquinas que están disponibles las 24 horas del día, pase lo que pase.
Como propietario del producto, necesito mejorar para poder asistir a la reunión de planificación de la iteración. 5 puntos.
Relacionado y posible duplicado: pm.stackexchange.com/questions/27590/…

Respuestas (2)

Esto es algo que debe abordarse en el plan de gestión de riesgos del proyecto. Si no ha identificado a las personas en el nivel del proyecto o de la iteración que son cruciales para el éxito y los métodos para continuar trabajando cuando no están disponibles, este es el momento perfecto para hacerlo, tan pronto como el equipo esté presente. Una de las cosas que debe hacer es identificar suplentes para los roles para que ninguna posición sea de profundidad.

Mientras tanto, todo el equipo debería poder continuar, en su mayor parte.

El Scrum Master puede facilitar su Sprint Review. Si puede tener un representante de un cliente o usuario disponible, sería beneficioso para demostrar sus funciones a las partes interesadas y recibir comentarios. Dado que el propietario del producto no está presente, podría ser una buena idea hacer una grabación de la reunión de alguna manera (una grabación de video, una grabación de audio, una captura de pantalla y notas) y presentarlas para su revisión a su regreso.

Si su Product Owner está involucrado en su Sprint Retrospective, también continuaría según lo planeado, solo que sin el Product Owner. Después de todo, está reflexionando sobre el desempeño de su equipo y cómo manejó los problemas y logró los éxitos. El Scrum Master, como guardián del proceso, debe conocer los objetivos en términos de puntos de la historia, características y problemas que surgieron. Una vez más, dado que no está presente una parte interesada crítica, recomendaría capturar algún tipo de esquema de la discusión y los hallazgos.

Si su Revisión de Sprint y Retrospectiva de Sprint son una sola reunión, cualquier persona que no esté directamente involucrada en el proceso no debe participar en la retrospectiva. Por ejemplo, mencioné que un representante diferente del cliente o grupo de usuarios podría participar en la Revisión del Sprint en lugar del Propietario del producto. Si esta persona no ha trabajado de cerca con el equipo, se le pedirá que sea un observador silencioso de la retrospectiva (lo que puede ser útil para capacitarlo como Propietario del Producto alternativo) o que abandone la sala por completo.

Al regreso del Dueño del Producto, recomendaría que el Scrum Master y quizás un miembro del Equipo de Desarrollo les informen sobre los resultados de la revisión del sprint y la retrospectiva del sprint. Con las grabaciones y las notas de las reuniones adecuadas, el propietario del producto debería poder leerlas y tener una breve discusión con el Scrum Master y el miembro del equipo si tiene alguna pregunta o inquietud.

En cuanto a la planificación de sprints, el trabajo del propietario del producto es actualizar continuamente la cartera de pedidos del producto con nuevas historias y mantener la prioridad. En cualquier momento dado, se debe priorizar la cartera de productos. Su Scrum Master debería poder tomar datos históricos del proyecto y liderar al equipo en el proceso de estimación de historias. Luego, el equipo puede extraer la cantidad adecuada de historias en función de los sprints anteriores.

Estoy de acuerdo con la revisión. Pero para la planificación, sin la orden de compra para dar detalles sobre los requisitos, puede ser difícil interpretar un elemento de la cartera de productos, ¿verdad?
@xsAce ¿Documentación?
@xsAce: no sé qué herramienta está utilizando, pero nuestra herramienta permite priorizar el trabajo pendiente y la nevera.
@Chad Solo usamos post its
@xsAce Una historia publicada debe tener suficientes detalles para entenderla. Una vez más, se trata de la gestión de riesgos, y puede haber algunas preguntas, pero si se encuentra en una situación en la que no puede avanzar, algo está mal en la forma en que está ejecutando el proyecto.
@xsAce: me resulta difícil creer que puede capturar toda la información que necesita para administrar de manera efectiva un proyecto de desarrollo de software cuando usa publicaciones para administrar sus historias, realizar un seguimiento de su progreso y priorizar su trabajo.
@ThomasOwens Gracias, bueno, la cuestión es que definimos todos los detalles suficientes de la historia DURANTE la planificación, no de antemano. Quiero decir que aquí es cuando ocurre la transferencia de conocimiento del PO al equipo. Por eso me resulta difícil sostener una planificación sin él. No estoy en una situación en la que no tengamos nada que hacer, siempre hay espacio para trabajar, reducir la deuda, etc... Pero incluir nuevas historias y hacer un nuevo sprint que aporte valor directo es algo que tengo. dificultad para ver suceder.
@xsAce Recomendaría que el PO se asegure continuamente de que las historias de mayor prioridad estén suficientemente documentadas para que puedan desarrollarse y probarse en su ausencia. Si bien la transferencia de conocimientos en una reunión de planificación es buena para que todos estén en sintonía, creo que debe tener suficiente información para hacer algo, incluso si es un trabajo preliminar. Si no puede entregar algo de valor al final de su sprint programado debido a la desaparición de una persona, debe revisar su proceso para eliminar ese conocimiento total en una sola persona.
@ThomasOwens Si bien estoy de acuerdo en que una persona desaparecida no debería interrumpir el sprint, no estamos hablando de un miembro del equipo aquí. Me refiero a que el rol de PO es crítico y REQUERIDO por el proceso. Si pudiera revisarse tan fácilmente, no lo necesitaríamos en primer lugar. La responsabilidad sería compartida directamente por el equipo. Creo que la solución tiene más que ver con la empresa y encontrar a alguien que reemplace al PO temporalmente que con revisar el proceso. Pero gracias
@xsAce El PO es miembro del equipo Scrum. Un equipo Scrum está formado por el propietario del producto, el equipo de desarrollo de productos de funciones cruzadas y el Scrum Master. El PO podría, en algunos casos, también ser miembro del equipo de desarrollo de productos. Independientemente de quién sea el propietario del producto y qué otras funciones desempeñe, es esencial que tenga en cuenta los momentos en los que no está disponible y lo trate como un riesgo que tiene una estrategia de mitigación. Una estrategia de mitigación simple es tener una OP alternativa que esté informada de todas las decisiones y comunicaciones, pero que en realidad no tome decisiones a menos que sea necesario.
@ThomasOwens está bien, ya entendí tu punto.
+1 para el punto clave "... tener un PO alternativo que esté informado de todas las decisiones y comunicaciones, pero que en realidad no tome decisiones a menos que sea necesario".
"Tu revisión de sprint puede ser realizada por el Scrum Master, que parece muy adecuado para esto. Después de todo, estás reflexionando sobre el desempeño de tu equipo y cómo manejaste los problemas y lograste los éxitos. El Scrum Master, como guardián del proceso, debe estar al tanto de los objetivos en términos de puntos de la historia, características y problemas que surgieron. Se puede presentar un resumen al propietario del producto a su regreso". ..... Oye, Thomas, ¿quisiste decir "retrospectiva de sprint" aquí? Parece que estás hablando de la retrospectiva, no de la demostración de sprint (también conocida como revisión de sprint).
@jmort253 En el último equipo de scrum en el que estuve (que fue hace ~9 años), eran lo mismo. Hubo 1 reunión al final del sprint donde el equipo demostró las historias completas y evaluó lo que salió bien o mal durante el sprint. Fue una revisión y reevaluación tanto del producto como del proceso antes de la planificación del sprint. En base a otras cosas que estoy leyendo, combinar la demostración del producto (la revisión) y la revisión de la ejecución (la retrospectiva) en una sola reunión no es poco común y es algo que recomendaría para garantizar que todas las partes interesadas estén presentes. e involucrado.
@ThomasOwens: por lo que he leído, la retrospectiva del sprint solo involucra al equipo scrum; de lo contrario, es posible que las personas no se sientan cómodas hablando sobre cualquier problema que tengan, especialmente si algunas de las partes interesadas son gerentes, ejecutivos o clientes. De acuerdo con la Guía de Scrum , la revisión y la retrospectiva son reuniones separadas, y según Michael James, Mike Cohn y mi instructor de CSM, solo el Equipo Scrum (y en algunos casos solo SM y el equipo de desarrollo) asisten a la retrospectiva.
[continuación] - Podría valer la pena aclarar que practicó una versión modificada de scrum para que la gente no se confunda entre revisión y retrospectiva cuando se trata de scrum. Espero que esto ayude a aclarar, y gracias por sus mensajes. ¡Nos están ayudando mucho en nuestro avance hacia Agile y Scrum!
@ jmort253 Gracias por eso. Editaré para aclarar. Y investigando un poco más, parece que los participantes en una retrospectiva pueden ser un tema polémico: algunas personas dicen que agrega valor para un PO mientras que otros afirman (como usted dice) que es solo para el equipo. Voy a aclarar esta respuesta ahora. Agradecería comentarios sobre las ediciones.

Es obvio que cuando no se dispone de PO nada será igual. Pero, por supuesto, el equipo debe hacer un esfuerzo para disminuir el daño al sprint. Creo que SM debería liderar el equipo de tal manera que el equipo pueda trabajar en tareas aclaradas y dejar las tareas poco claras para el momento en que PO esté disponible. A modo de scrum, el proyecto continúa paso a paso dejando algunas partes para decidir más adelante. Por lo tanto, la máxima disponibilidad es crítica.

¿Qué haces si el Product Owner está enfermo?
RespuestasAquíPolítica de privacidad1y, 0v