¿Qué sucede cuando se completa el PBI en un sprint pero el timebox del sprint no ha expirado?

Sé que si los PBI no se pueden completar dentro de un sprint, se pueden volver a negociar con el propietario del producto

Ahora, de nuevo, un sprint no se puede acortar ni alargar más allá del cuadro de tiempo acordado, a menos que el objetivo del sprint sea obsoleto. Entonces, ¿cómo se desarrolla la situación cuando se cumple la definición acordada de hecho antes de que expire el plazo?

Respuestas (5)

Al ser un marco y no un proceso o método estricto, Scrum no dicta lo que debería suceder. El propietario del producto y el equipo de desarrollo deben trabajar juntos para determinar el mejor curso de acción. Esto es muy parecido a una situación en la que parece que está en peligro completar los elementos seleccionados.

Hay varias opciones posibles sin ningún orden en particular:

  • Agregue un elemento adicional de la cartera de productos que el equipo de desarrollo crea que puede completar antes del final del Sprint
    • Se aplica a Sprint Goal (o no)
    • Aumenta una característica existente (o no)
  • Utilice el tiempo para las actividades del equipo.
    • Celebra los logros
    • Aprendizaje y formación
    • trabajo en equipo
  • Atender cualquier deuda técnica
  • Pruebas exploratorias adicionales
  • Refinamiento de la cartera de pedidos

NOTA: La Definición de "Terminado" se aplica a cada Elemento de la Lista de Producto pronosticado por el Equipo de Desarrollo que se ha agregado a la Lista de Pendientes de Sprint, así como al Incremento en su totalidad.

La guía Scrum

Hay algunas opciones. Sin embargo, la Guía Scrum no dice qué hacer.

Primero, el equipo de desarrollo puede comenzar a trabajar en el siguiente elemento del Product Backlog. Idealmente, hay más elementos que se han perfeccionado por completo en la cartera de pedidos. El propietario del producto debe asegurarse de que la cartera de productos esté siempre en un buen orden de prioridad y que los elementos principales se hayan refinado lo suficiente para funcionar en un Sprint próximo.

En segundo lugar, el equipo de desarrollo puede perfeccionar sus habilidades. Use esto como una oportunidad para el entrenamiento cruzado. Esto también puede extenderse, hasta cierto punto, al Scrum Master y al Product Owner. Considere no solo las habilidades técnicas que necesita cada rol para hacer su trabajo diario, sino también mejorar la comprensión del trabajo realizado por los otros roles del equipo.

Tercero, pagar la deuda técnica. Mejore la cobertura de pruebas automatizadas, mejore la cobertura de pruebas manuales (si tiene pruebas manuales), convierta las pruebas manuales en pruebas automatizadas, cree herramientas para facilitar el proceso de desarrollo, refactorice partes de la aplicación, adquiera experiencia en otras partes del código que el equipo pueda no haber estado expuesto recientemente. Haz cosas para que el próximo Sprint sea más fácil.

También puede haber otras opciones, dependiendo de su organización. Ayudar a otros equipos a cumplir compromisos, revisiones de código, pruebas adicionales.

En cualquier caso, el Equipo de Desarrollo y el Propietario del Producto deben trabajar juntos para determinar la mejor alternativa. Quizás la gerencia de la organización también pueda mirar hacia las cosas que deben hacerse. Esto también es algo que debe discutirse en la Retrospectiva de Sprint para determinar cómo ser más precisos en la planificación de la capacidad en los próximos Sprints.

"Ayudar a otros equipos a cumplir con los compromisos" definitivamente interferiría con el empirismo. Si las revisiones de código no son parte de la definición de "Terminado" (y no están cubiertas por la programación en pares), entonces tal vez eso deba abordarse.
@AlanLarimer ¿Cómo interfiere con el empirismo? El hecho de que un equipo necesitaba recursos adicionales aún debería surgir en una Retrospectiva de Sprint y el equipo debería llegar a las causas fundamentales (y las soluciones asociadas) que llevaron a este estado. También está en el área de la profesionalidad: si tengo conocimientos y habilidades que pueden ayudar a otro equipo a tener éxito sin ponerles una carga, lo haré. Es bueno para la organización en su conjunto asumir compromisos y ofrecer valor a los clientes y usuarios.
Afecta el empirismo de ese segundo Equipo Scrum porque tanto los productos como los resultados de ese Sprint se han visto afectados. Ya sea que el problema sea la necesidad de recursos o capacitación adicionales, o simplemente las incógnitas y las complejidades que surgieron durante el curso del trabajo, se pueden inspeccionar independientemente. Sin duda, se desea la profesionalidad del intercambio de conocimientos, y el marco no prohíbe ayudar a otro Equipo Scrum, probablemente haya formas más efectivas de lograr los resultados deseados. "Compromisos" no son lo mismo que "previsiones", especialmente en este contexto.
"probablemente hay formas más efectivas de lograr los resultados deseados". - Suena como una buena oportunidad para otra pregunta .
@AlanLarimer La definición de empirismo con la que estoy familiarizado es simplemente que el conocimiento proviene de la experiencia. Si los equipos están en el día 6 o 7 de un Sprint de 10 días y el Equipo A ha alcanzado sus Objetivos de Sprint y el Equipo B está luchando, el Equipo B tiene y está experimentando la lucha. El equipo A que brinda cualquier tipo de ayuda no afecta el hecho de que el equipo B tiene nuevos conocimientos sobre los que reflexionar. El Equipo B puede aprender y aplicar soluciones en la Retrospectiva de Sprint y el Equipo A puede respaldar objetivos organizacionales más amplios. Simplemente no veo cómo este no es el resultado deseado y cómo esto no es empirismo en el trabajo.
El empirismo es el conocimiento a partir de la experiencia. La dificultad de comprender la experiencia, por tanto el conocimiento adquirido, se complica al aumentar el número de variables; por lo tanto, identificar y abordar los problemas de raíz también se vuelve más difícil.
  • A) Renegociar el alcance. Si tiene suficiente capacidad restante y elementos pendientes disponibles, ¿por qué no hacer otro?
  • B) Refinamiento. Trabaja un poco más en la preparación del back log para futuros sprints.
  • C) Servicio de limpieza. Aborde la deuda tecnológica, mejore las pruebas, realice una revisión de código, realice un análisis de código estático, evalúe formas de mejorar su proceso de scrum
  • D) Exploración: aprender algo, asesorarse unos a otros, probar una idea para una próxima tarea
  • E) "Descansa". Probablemente también disfrutes de los sprints apretados. Sprints en los que dedicas horas adicionales para hacer todo. Considere esto como la otra cara.

Yo diría, suponiendo que completar todas las Historias haya logrado el Sprint Goal (que es probable pero no garantizado), que el Sprint Goal ahora está obsoleto. Generalmente, cuando se decide un Sprint Goal, no debe ser algo que ya se haya logrado. De la misma manera, una vez que se logra una Meta, se vuelve obsoleta.

Y así, según la Guía Scrum ,

Cuando se cancela un Sprint, se revisan todos los elementos del Backlog de producto completados y "Terminados". Si parte del trabajo es potencialmente liberable, el propietario del producto normalmente lo acepta. Todos los elementos incompletos de la cartera de productos se vuelven a estimar y se vuelven a colocar en la cartera de productos.

Entonces, revisa todo el trabajo en el Sprint (el Sprint Review), luego devuelve... nada al Backlog, ya que no hay trabajo incompleto.

Luego tenga su Retrospectiva, donde discuta su éxito (en el logro de la Meta) y el fracaso (en la estimación adecuada del trabajo).

... Por supuesto, como se mencionó, esto es solo si realmente completaste el Sprint Goal. Si no es así, descubra lo que necesita para hacerlo, luego hágalo.

Esto también supone que su organización no depende de esos plazos. Si tiene más sentido en su caso específico simplemente generar más trabajo (ya sea el trabajo típico de "características" o la reducción de la deuda técnica o la investigación o...), entonces hágalo.

"fracaso (en la estimación adecuada del trabajo)" es nada menos que una expresión en la comprensión errónea de la naturaleza del trabajo complejo. Obsoleto no se aplica ya que el Sprint Goal sigue siendo aplicable y merece ser discutido en la Revisión del Sprint.
@AlanLarimer No entiendo lo que quiere decir con su primera oración, ¿puede aclararlo? Y consideraría que una meta que se ha logrado ya no es una meta. Por ejemplo, si tenía la meta de bajar a 150 libras y luego bajó a 148 libras, en ese punto, tener la meta de bajar a 150 libras no tendría sentido. Puede (y debe) todavía ser discutido en la Revisión, estoy de acuerdo. Pero ya no es un Goal ... Creo que solo tenemos una diferencia en la interpretación de la palabra.
El trabajo complejo involucra incógnitas y posiblemente aprendizaje; esperar una estimación adecuada de cuándo resolver la ejecución de dicho trabajo es un indicador de un malentendido de la naturaleza de la complejidad. ¿Cómo afectaría al equipo de desarrollo, al equipo Scrum, a la organización, a los usuarios, etc., la cancelación periódica, frecuente o esporádica de Sprints debido a su finalización anticipada ?
Por supuesto, esperar estimaciones correctas todo el tiempo es absurdo. Ningún Equipo es perfecto, pero eso no significa que no deban intentarlo , y en consecuencia tomar nota y examinar cuando fallan. (Esto supone que no hay penalización organizacional por el fracaso. Si el Gran Jefe le va a regañar por cualquier fracaso, entonces no, no considere un Sprint temprano como un "fracaso"). de cancelar Sprints, eso depende en gran medida del entorno de la organización; por eso agregué el último párrafo a mi respuesta.

Hable con el equipo Scrum para:

  • Cree más cobertura de prueba (automatizada)
  • Eliminar deuda técnica
  • Ejecutar acciones resultantes de retrospectivas, si aún no están planificadas
  • Extraiga el elemento más importante a continuación en la cartera de pedidos, si está refinado.
  • Cualquier otra idea que tenga el equipo

Solo usa el sentido común y deja que el equipo decida.

La lista que di es el orden en que lo hace mi equipo actual, la mayoría de las veces resulta en obtener más trabajo después de limpiar un poco el código base.

¿Qué sucede cuando se completa el PBI en un sprint pero el timebox del sprint no ha expirado?
RespuestasAquíPolítica de privacidad1y, 0v