Confundido sobre la modificación de la acumulación de sprint durante un sprint

He estado leyendo mucho sobre scrum últimamente, y he encontrado lo que me parece información contradictoria sobre si está bien o no cambiar el retraso del sprint durante un sprint. El artículo de Wikipedia sobre scrum dice que no está bien, y varios otros artículos también lo dicen. También mi profesor de Desarrollo de Software enseñó lo mismo durante una descripción general de scrum.

Sin embargo, leí Scrum y XP de las trincheras y eso describe una sección para elementos no planificados en el tablero de tareas. Entonces busqué la Guía Scrum y dice que durante el sprint "No se realizan cambios que afecten el Objetivo Sprint" y en la discusión del Objetivo Sprint "Si el trabajo resulta ser diferente al esperado por el Equipo de Desarrollo, luego colaboran con el Propietario del producto para negociar el alcance del Backlog de Sprint dentro del Sprint ". Continúa diciendo en la discusión del Backlog de Sprint:

El Backlog de Sprint es un plan con suficiente detalle para que los cambios en progreso se puedan entender en el Daily Scrum. El equipo de desarrollo modifica el Backlog de Sprint en todo el Sprint, y el Backlog de Sprint emerge durante el Sprint. Este surgimiento ocurre cuando el Equipo de Desarrollo trabaja a través del plan y aprende más sobre el trabajo necesario para lograr el Objetivo Sprint.

Como se requiere un nuevo trabajo, el equipo de desarrollo lo agrega a la reserva de Sprint. A medida que se realiza o completa el trabajo, se actualiza el trabajo restante estimado. Cuando los elementos del plan se consideran innecesarios, se eliminan. Solo el Equipo de Desarrollo puede cambiar su Backlog de Sprint durante un Sprint. El Backlog de Sprint es una imagen muy visible en tiempo real del trabajo que el Equipo de Desarrollo planea realizar durante el Sprint, y pertenece únicamente al Equipo de Desarrollo.

Entonces, en este punto, estoy completamente confundido. Pensando en ello, tiene más sentido para mí adoptar el segundo enfoque. Los elementos individuales y específicos en la cartera de pedidos no me parecen lo más importante, sino más bien el objetivo del sprint, por lo que no tiene sentido cambiar el objetivo del sprint, pero poder cambiarlo. Por ejemplo, si tanto el propietario del producto como el equipo pensaron que estaban en la misma página sobre una historia, pero a medida que avanzaba el sprint descubrieron que había un malentendido, parece que tiene sentido cambiar las tareas que conforman esa historia en consecuencia . O si hubo alguna historia o tarea que se olvidó, pero se requiere para alcanzar la meta del sprint, creo que sería mejor agregar la historia o la tarea al trabajo atrasado durante el sprint.

Sin embargo, hay muchas personas que parecen bastante firmes de que cualquier cambio en el retraso del sprint no está bien. ¿Estoy malinterpretando esa posición de alguna manera? ¿Están esas personas definiendo el backlog de sprint de alguna manera diferente? Entiendo que el backlog de Sprint es que consiste tanto en las historias como en las tareas en las que se desglosan.

De todos modos, realmente agradecería la opinión sobre este tema. Estoy tratando de descubrir cuál es el enfoque ideal de scrum para cambiar el retraso del sprint durante un sprint, y si las personas que usan scrum con éxito para el desarrollo permiten cambiar el retraso del sprint durante un sprint.

Primero, no tendría reglas estrictas al respecto; el objetivo de scrum es permitirte adaptarte a la situación. Por lo tanto, debe poder modificar el retraso del sprint durante el sprint si es absolutamente necesario (como si hubiera olvidado algo crítico).

Pero decir esta modificación a la acumulación de sprint durante el sprint debe ser resistido. El punto principal del sprint es que el nuevo trabajo se puede agregar al siguiente sprint (después de que se haya priorizado correctamente) sin afectar la línea de tiempo general del proyecto (múltiples sprints).

Pero si el trabajo es crítico para una de las tareas en este sprint, tiene dos opciones.

1. Añadir nuevo elemento al sprint.
   PERO eliminar un elemento de tamaño equivalente del sprint.
2. Suelta el elemento que se planeó mal de este sprint (para que puedas planificarlo adecuadamente en el próximo sprint).
   • Agregar una alternativa (del tamaño apropiado) desde la parte superior de la cartera de pedidos del producto (que debería estar en orden de prioridad de su reunión de planificación de sprint).
   • O cuando todos los artículos de sprint estén terminados, permita que los desarrolladores recojan la holgura de la cartera de productos.

Así que estoy en el campamento para que probablemente no debas modificar el retraso del sprint. Pero debe tener en cuenta la situación, puede haber circunstancias excepcionales. En la mayoría de los casos, iría con las opciones 2 y dejaría que los desarrolladores recojan la holgura con las tareas del trabajo atrasado.

Luego, en la próxima reunión de planificación, la nueva tarea se analizará adecuadamente y se agregará al sprint (según corresponda).

Recuerde que el sprint es corto y solo la marca de la próxima caída, no el final del ciclo de desarrollo. El propietario del producto tendría que estar muy desesperado por una característica que no podía esperar hasta el final del próximo sprint.

La confusión se debe al lenguaje ambiguo.

El Backlog de Sprint tiene dos niveles de detalle. Primero, es una lista de Artículos (Historias de usuarios) que el Equipo se ha comprometido a entregar. En segundo lugar, son todas las TAREAS que el equipo intenta hacer para entregar cada una de esas historias.

Entonces, cuando las personas hablan sobre el Backlog de Sprint, realmente deben tener claro lo que significan. Cuando lea la Guía Scrum, verá que dice: El Backlog de Sprint es el conjunto de elementos del Backlog del Producto seleccionados para el Sprint, más un plan para entregar el Incremento del producto y alcanzar el Objetivo Sprint.

Por lo tanto, AMBOS son la lista de Elementos del Backlog del Producto Y el Plan (Tareas) para entregarlos.

Ahora, a muchos equipos les gusta agregar todas las tareas propuestas (plan) al comienzo del Sprint para que puedan rastrear un gráfico de quemado basado en las horas que quedan por hacer. Otros equipos permiten que las tareas surjan según sea necesario. ESTO es cuando está bien agregar al 'Backlog de Sprint', ya que el equipo tiene que hacer eso para inspeccionar y adaptarse para entregar los Artículos y cumplir con el Objetivo de Sprint.

Bajo ciertas circunstancias, un equipo puede adelantarse al cronograma y (habiendo eliminado todas las demás tareas útiles que podrían mejorar las capacidades del Equipo) puede decidir trabajar con el Propietario del producto para seleccionar otra historia (ya debería haber sido priorizada y dimensionada) de la cartera de pedidos del producto ... pero solo si tienen la confianza de que se completará dentro de ese Sprint y que se alinea con el objetivo de Sprint.

Así que ahí lo tenemos; SÍ ... los equipos agregan Tareas al plan de Sprint Backlog según sea necesario. NO, por lo general no se agregan a la lista de elementos de la lista de tareas pendientes que definen el alcance del Sprint.

Espero que esto aclare la situación.

Depende de tus situaciones. Si se pierde alguna información durante la planificación, y luego se da cuenta de que necesita modificar o agregar algunos puntos a algunas historias, entonces creo que está bien. Pero sí, si el alcance de una característica cambia completamente, entonces esa es una situación extrema y debe manejarse de manera diferente.

Pero, por supuesto, durante la planificación, se supone, que todos conocen y discuten claramente sobre cada una de las características en las que estarían trabajando. Si las discusiones y la planificación son buenas, entonces en casi todos los casos realmente no necesita ninguna modificación.

Estoy de acuerdo con las respuestas, señalaría que si la historia ha comenzado a desarrollarse, entonces no se puede detener hasta que esté hecha.

Cava tus talones desde el principio. Aquellos que soliciten el cambio tendrán que aprender de la manera difícil, de lo contrario, terminarás con la planificación sin valor si la gente aprende que puedes hacer lo que quieras de todos modos.

Cite que la calidad proviene del enfoque y los errores provienen de dejar caer un tren de pensamiento. Cite el costo del cambio de contexto. El seguimiento de la deuda y la gestión de escribir, discutir y jugar una historia para abordar el trabajo a medias es costoso. Simplemente no empieces por esta ruta.

Idea: dar a la gerencia 3 créditos de cambio para gastar cada trimestre como compromiso.