¿Debo eliminar una historia de usuario de un sprint en curso si sé que no podemos completarlo?

En el sprint, ¿podemos eliminar (pasar al próximo sprint) las historias planificadas (mitad del sprint), si estamos 100% seguros de que no podemos completarlas?

Ejemplo dado:

  • Supongamos que planeamos completar 5 historias en un sprint.
  • A mitad del sprint, estamos seguros de que una historia no se puede completar debido a las dependencias (u otra razón).
  • Ahora, ¿podemos eliminar esta historia para que solo tengamos 4 historias en el sprint actual (y un avance más limpio)?

Creo que no podemos hacer eso, pero tengo dudas.

La idea es que si eliminamos las historias de usuario (que no se pueden completar), tendríamos un gráfico de trabajo pendiente más limpio.

¿Cuál es la forma correcta de abordar este problema?

Como regla general, si está haciendo cosas solo para hacer que su gráfico sea más ordenado, probablemente sea una mala idea.

Respuestas (5)

De la Guía Scrum:

Durante el Sprint:

  1. No se realizan cambios que puedan poner en peligro el Sprint Goal;
  2. Los objetivos de calidad no disminuyen; y,
  3. El alcance puede aclararse y renegociarse entre el propietario del producto y el equipo de desarrollo a medida que se aprende más.

Los cambios que mencionas caen en la última categoría, a menos que pongan en peligro alcanzar el objetivo del sprint. Si la última historia que propone eliminar es la menos importante, las posibilidades de que ponga en peligro el objetivo del sprint son menores.

Si esto sucede con frecuencia, dedique una o dos retrospectivas a descubrir cómo podría evitarlo. ¿Estás asumiendo demasiado trabajo al comienzo del sprint para empezar? ¿El equipo necesita capacitación? ¿Había demasiadas cosas poco claras cuando comenzó el trabajo? (¡Sin embargo, tenga cuidado de no comenzar a hacer un análisis de cascada completo!).

Su trabajo pendiente ahora reflejará la nueva situación y ahora debería mostrar que está nuevamente encaminado para la entrega oportuna del nuevo alcance. Recuerde que Burndown es una práctica que el equipo puede usar para ver si todavía están en camino de entregar lo que pronosticaron. Si hacen un nuevo pronóstico (es decir, renegocian el alcance), el trabajo pendiente reflejará el nuevo estado. Si Burn down se usa para otros fines que no sean el seguimiento del progreso interno del equipo, es posible que sea necesario explicar la caída repentina. Como entrenadores de Scrum, generalmente advertimos que no se debe compartir el trabajo pendiente como un informe oficial al final del sprint. Ese no es su propósito y puede llevar a que las personas hagan suposiciones incorrectas.

Usted menciona un informe de revisión de Sprint. Este no es un artefacto oficial de scrum, por lo que no puedo contar una historia oficial sobre cómo se debe influir. Suena como un informe del propietario del producto a las partes interesadas. Si el propietario del producto comunicó previamente el pronóstico del equipo, entonces puede explicar que ciertas funciones no se entregaron. Pero durante la reunión de revisión del Sprint, de hecho, demostrará que todo lo que ha entregado es ecológico (Hecho de acuerdo con el Departamento de Defensa). Lo que también será visible es que su velocidad será más baja de lo habitual, lo que puede generar algunas preguntas.

El Scrum Master debe asegurarse de que el equipo de desarrollo analice la causa subyacente que provocó que sucediera este cambio. El momento natural para hacerlo es en la Retrospectiva. Tenga cuidado de que el equipo simplemente reduzca su pronóstico o cree una larga lista que pueden llamar una "definición de listo". Es mejor cuando el equipo trata de aplicar la automatización para reducir los gastos generales de prueba e implementación y cuando el equipo tiene comunicaciones más frecuentes sobre la intención real del PBI para que lo entiendan mejor.

Gracias, pero estaba pensando que no debería permitirse del todo (dejar caer una historia a mitad de camino). Ahora supongamos que lo hacemos, ¿cuál sería el impacto en a) el quemado b) el informe de Sprint Review: mostraríamos una velocidad planificada reducida, que podemos lograr y todo se vería verde?
@LalitSinghRana, si se descarta la historia, el avance le mostrará que terminará antes de tiempo. La revisión del sprint debería cubrir esto y el motivo (se tuvo que descartar una historia). Luego, la retrospectiva debe examinar las razones por las que la historia tuvo que descartarse y cómo evitar programar una historia demasiado pronto en el futuro.

El backlog de Sprint es un pronóstico, no un compromiso

En la revisión de 2011 de la Guía Scrum, Jeff Sutherland y Ken Schwaber hicieron un cambio importante. Cambiaron la palabra "compromiso" a "pronóstico" con respecto a la acumulación de Sprint.

El término compromiso tiene dos malas consecuencias :

  1. Las partes interesadas esperan que se entregue cada elemento al final del Sprint, a cualquier precio. Y, lo que es peor, comienzan a hacer planes, suposiciones y decisiones basadas en este hecho aún no confirmado.
  2. El equipo de desarrollo se enfoca en entregar cada elemento de funcionalidad que se prometió al comienzo del Sprint a cualquier precio... incluso a expensas de la calidad del software o el valor comercial real que se entrega.

Ahora, ¿podemos eliminar esta historia para que solo tengamos 4 historias en el sprint actual (y un avance más limpio)?

Lo que sea que pronostique en el momento de la planificación de Sprint es la línea de base. Quiere mostrar que una historia no está completa. Si manipula la línea de base, barrerá los problemas debajo de la alfombra y el equipo perderá la oportunidad de aprender de ellos.

¿Cuál es la forma correcta de abordar este problema?

Nuevamente citando la Guía Scrum, "Si el Equipo de Desarrollo determina que tiene demasiado o muy poco trabajo, puede renegociar los elementos seleccionados de la Lista de Producto con el Propietario del Producto".

Dijiste que a mitad del sprint decidiste que una historia no se puede hacer. Esta es una situación mejor que descubrir esto al final del sprint. Comience a hablar con el propietario del producto. Si una historia está bloqueada, tal vez haya otra historia que pueda incluir en este sprint.

Y discuta esto en el momento de la retrospectiva para ver cómo evitar esto en el futuro:

  1. Si descubrió que una historia está bloqueada, es posible que desee hacer el trabajo previo para evitar dicho bloqueo en el futuro.
  2. Si asumió demasiado trabajo, es posible que sus historias sean demasiado grandes o estén mal estimadas.
  3. Si descubrió más alcance del que estimó, tal vez el equipo debería dedicar más tiempo a las reuniones de refinamiento del trabajo pendiente para preparar las historias con criterios de aceptación claros.
solo una cosa, el siguiente comentario viene durante la reunión de planificación y no después de la planificación. "Si el equipo de desarrollo determina que tiene demasiado o muy poco trabajo, puede renegociar los elementos seleccionados de la lista de pedidos del producto con el propietario del producto".
Sí, pero si durante el sprint descubres que no puedes continuar con una historia, sigues este mismo proceso y renegocias con el propietario del producto.
"Si una historia está bloqueada, tal vez haya otra historia que pueda incluir en este sprint". - ¿Es esto realmente una buena idea? ¿No deberías continuar con las cosas que ya están en el Sprint y luego hacer otra historia si te sobra tiempo al final?
Ese puede muy bien ser el caso. Pero corresponde al Product Owner decirlo, teniendo en cuenta el Sprint Goal.

Creo que si es tu proyecto, entonces puedes decidir si está permitido o no. debe considerar el impacto de esta decisión:

  • ¿Dañará el enfoque del equipo si pueden elegir la manera fácil de abandonar una historia en lugar de luchar por ella, o reducirá la presión sobre ellos?
  • ¿Cuáles son las consecuencias si se vuelve normal reducir los compromisos? ¿Cómo puedes evitar que se vuelva normal?
  • ¿Cómo afectará las previsiones y el seguimiento del estado? seguramente reducirá la velocidad, pero ¿hay algún compromiso que se base en la velocidad actual y deba reevaluarse?

siéntete libre de lo que consideres útil para tu proyecto, pero piensa en el impacto del cambio. a veces vale la pena cambiar los procesos.

(por cierto, si la pregunta es si Scrum permite este enfoque o no, la respuesta es no; debe esforzarse por entregar todo lo que se comprometió, dentro de los límites de la sostenibilidad y la calidad, y si no se hace para la demostración, debe agregar el trabajo restante a la cartera de pedidos del producto y, eventualmente, a la cartera de pedidos del próximo sprint; también debe verificar si el sprint ha fallado)

Aunque es su proyecto y usted puede decidir, ya no se adherirá a los valores de scrum si impulsa constantemente las historias pronosticadas si son una parte esencial del objetivo del sprint. Al final, el objetivo debe ser no tener que hacer esto.
Scrum le permite renegociar el alcance de la acumulación de sprint. No tiene sentido empezar a trabajar si ya sabes que no lo vas a terminar. Pero pone algunas reglas (ver mi otra respuesta). Este es un error común. Pero al adherirse a los valores de scrum, el equipo debe encontrar una mejor manera de no tener que renegociar constantemente el alcance.
sí, es una crítica común de mi trabajo que no respeto adecuadamente los valores de scrum, sino que me enfoco en el éxito del proyecto y la satisfacción del cliente;) además, considero toda la metodología como una guía y un punto en común, no como algo que está grabado en piedra. de hecho, Scrum le permite renegociar la acumulación, pero solo en casos excepcionales (como cambios en la capacidad del equipo o que finalicen antes). sin embargo, enfatiza que el equipo debe hacer un esfuerzo para mantener sus compromisos, y no se recomienda evitar esto reduciendo el alcance del sprint.
Correcto. No debería ser el estándar. Pero comenzar a trabajar en algo que no se puede terminar obliga al equipo y al propietario del producto. Ese elemento ahora debe ser parte del próximo sprint o eliminarse del incremento (o debe implementar prácticas de bifurcación o alternar funciones para manejar esto). Es mejor no comenzar ningún trabajo que sepa que no puede terminar y buscar algo en la cartera de pedidos que realmente pueda terminar (a menos que falle en el objetivo del sprint). El marco de Scrum permite estos cambios, pero inherentemente no le gustan.
seguro. a veces puede ser beneficioso para el equipo si se enfrentan a las consecuencias negativas de comprometerse demasiado, por lo que pueden sentir que sus decisiones en la planificación del sprint tendrán un impacto en su trabajo para el próximo período, pero si se usa en exceso, esto puede conducir a estimaciones exageradas o compromisos demasiado defensivos, que no es el resultado al que debemos aspirar. a veces, el PM que rompe las reglas para facilitar la vida del equipo los motiva (ya que sienten que el PM está de su lado), pero si se usa en exceso, puede conducir a una velocidad de trabajo cómoda (perezosa). todo depende.
Aquí es donde el Scrum Master puede ponerse su sombrero de entrenador y mentor y realmente ayudar al equipo a mejorar. Debería detectar el "mal comportamiento" que mencionaste y, de hecho, desafiar tanto al PO como al equipo para salir de este problema. Pero si se enfrenta a una situación única en la que el pronóstico era demasiado grande por cualquier motivo. Solo renegociar ;).
Los problemas que describió en su último comentario no solo irían en contra de los valores de scrum (principalmente coraje y compromiso), sino también en contra del corazón de scrum: inspeccionar y adaptar.
deberíamos considerar seriamente desconectar nuestra discusión :) por lo que veo, tenemos casi la misma opinión, nuestra diferencia es el nivel de abstracción: piensas como un maestro scrum, cuyo papel es aplicar tu conocimiento y experiencia para resolver problemas usando Mentalidad de Scrum, y garantizar que los valores y procesos de Scrum se cumplan en la mayor medida posible. Pienso como PM, que es libre de elegir cualquier metodología, adaptarla a sus necesidades y cambiarla (con los procesos de cambio establecidos y considerando el impacto en el éxito del proyecto).
Es realmente interesante comparar los dos puntos de vista, coinciden bastante bien, tal vez en un nivel diferente de abstracción.

Sí, absolutamente puede eliminarlo, pero tendrá el siguiente entendimiento:

  • El equipo entiende y está de acuerdo por qué es necesario eliminarlo.
  • Se ha consultado al propietario del producto sobre la eliminación de la historia de usuario.

  • El equipo y el propietario del producto han tenido la oportunidad de renegociar el sprint con un intento de reemplazar el elemento de trabajo con algo valioso y procesable.

    • Todas las partes interesadas afectadas han sido consultadas y/o informadas del cambio.

-El equipo toma esto como una oportunidad de aprendizaje para hacer mejores estimaciones/compromisos de sprint en iteraciones futuras.

Para su información, eliminar la historia solo para tener un quemado más limpio no es una buena razón.

No debe eliminar las historias para que se quemen con más limpieza, ya que esto puede ocultar el problema subyacente. Cuando se queda en la pared y no se ha terminado al final del sprint, es un punto de partida para la discusión sobre la mejora. Esto se entiende por transparencia.

Un mejor enfoque sería colaborar con el propietario del producto para alcanzar el objetivo del sprint, tan pronto como detecte el problema .

El propietario del producto puede ayudar en cualquiera de las

  1. reduciendo la cantidad de trabajo para cada historia de usuario, pero de alguna manera el objetivo del sprint permanece intacto o
  2. priorizando las historias.
  3. El propietario del producto (y solo el propietario del producto) también podría decidir detener todo el sprint, si no ve ningún valor en continuarlo.
¿Debo eliminar una historia de usuario de un sprint en curso si sé que no podemos completarlo?
RespuestasAquíPolítica de privacidad1y, 4v