¿Quién debe asistir a Sprint Replanning?

Está claro que en Sprint Planning tiene que estar presente el Product Owner. Sin embargo, dado que el Equipo de Desarrollo es responsable del trabajo de sprint actual, ¿el PO debe asistir a la Replanificación? Aunque es probable que se modifique el objetivo del Sprint, solo el equipo de desarrollo sabe cuánto trabajo puede realizar y, por lo tanto, modificará el Sprint en función de su conocimiento.

Respuestas (2)

TL;DR

[D]ado que el Equipo de Desarrollo es responsable del trabajo de sprint actual, ¿el PO necesita asistir a la Replanificación? [sic]

Sí, el propietario del producto debe estar presente en todas las sesiones de planificación y determinación del alcance.

Es posible ajustar el alcance dentro de un Sprint, pero solo con la participación total del propietario del producto. Los cambios en el Objetivo del Sprint deberían desencadenar una Terminación anticipada del Sprint actual y un regreso a la Planificación del Sprint.

Cómo cambiar el alcance y los objetivos de Sprint en Scrum

No existe tal ceremonia como "Replanificación de Sprint". Parece que ha creado una ceremonia especial para eliminar el alcance del Sprint actual, pero Scrum ya admite este proceso dentro del marco estándar.

Ciertamente es posible reducir el alcance dentro de un Sprint, pero:

  1. El Dueño del Producto debe estar involucrado. No se pueden realizar cambios en el alcance planificado sin la participación del propietario del producto.
  2. Los cambios en el Sprint Goal solo se pueden realizar con el pleno acuerdo del Propietario del producto. El Sprint Goal representa un incremento planificado de valor, por lo que el Equipo de desarrollo no puede cambiar el Sprint Goal de manera unilateral.
  3. Un cambio en el Sprint Goal debe desencadenar una Terminación anticipada por parte del Product Owner y un regreso a Sprint Planning. Si el objetivo central de un Sprint se invalida por algún motivo, todo el equipo Scrum (incluido el propietario del producto) debe descartarlo y volver a planificarlo después de una breve retrospectiva del Sprint para identificar qué salió mal.

En definitiva, el Equipo de Desarrollo no puede recortar alcance ni cambiar objetivos sin la participación activa del Product Owner. Si lo hace, socava las responsabilidades principales del rol del propietario del producto y elimina los controles esenciales del proyecto del marco.

Esto se siente muy feliz para mí. Sí, se debe informar al PO cuando el alcance disminuye y preguntar qué se puede eliminar del sprint, pero para que desencadene una terminación anticipada es un proceso muy pesado. Los desarrolladores son cazados furtivamente todo el tiempo y las historias ocasionalmente resultan ser más grandes de lo que se pensaba. Es menos disruptivo reunirse y discutir la disminución del alcance sin toda la ceremonia. Además, no hay razón para que la disminución del alcance no pueda ser un tema en la retrospectiva ya planeada.
La guía de scrum está de acuerdo con el n.° 2 y el n.° 3, pero no con el n.° 1. El propósito del Sprint Goal es ralentizar el equipo de desarrollo para cambiar el alcance sin la intervención del PO.
@MrHinsh Eso es incorrecto. El Sprint Goal está diseñado para guiar los detalles de implementación , no para permitir que el Equipo de Desarrollo cambie el alcance unilateralmente. De hecho, la Guía Scrum dice explícitamente: "No se realizan cambios que pongan en peligro el Sprint Goal" ( The Scrum Guide , 2013; p. 7) definido durante la Planificación del Sprint para el incremento actual. Si aún no tiene claro esto, le recomiendo encarecidamente que abra una nueva pregunta para que pueda recibir respuestas más completas sobre este tema relacionado.
Bien dicho @CodeGnome. Esto es exactamente correcto y demuestra la flexibilidad de Scrum Framework para respaldar el principio de agilidad que establece: "Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente".

Gran pregunta. En mi experiencia, cada vez que ajustas el alcance del sprint o el objetivo del sprint, el propietario del producto debe participar. Pienso en el equipo de Scrum como el "equipo de entrega" y el equipo de entrega entrega lo que el propietario del producto haya determinado que es el trabajo de mayor valor. Entonces, tan pronto como dice ajustar el objetivo del sprint, pienso: "Está bien, el propietario del producto estableció el último objetivo del sprint, debemos informarle que no podemos lograrlo y que debemos volver a planificarlo". Además, incluso si el objetivo del sprint está intacto, y realmente solo tiene una disminución en la capacidad (tal vez un desarrollador fue cazado furtivamente), el propietario del producto debe determinar qué elemento de trabajo puede abandonar el sprint. ¿Tener sentido?

¿Quién debe asistir a Sprint Replanning?
RespuestasAquíPolítica de privacidad1y, 0v