Manejo de nuevas sugerencias para historias de usuario resueltas en sprint cerrado

En un proyecto administrado con el marco Scrum, tengo una situación en la que todas las tareas asociadas a una historia de usuario (característica) se realizaron con éxito. No se permiten más cambios de código ya que las pruebas están en progreso y el sprint está cerca de la fecha de cierre. Sin embargo, mientras probaba y revisaba el producto, yo, el propietario del producto u otros miembros del equipo, habíamos llegado con algunas sugerencias para la misma historia.

¿Cómo manejar estas sugerencias?

  • ¿Deberían crearse nuevas tareas en el nuevo sprint y vincularse a la historia en el sprint anterior?
  • ¿O debería crearse una nueva historia en el nuevo sprint con nuevas tareas?
  • ¿O hay una mejor práctica para tal escenario?

Respuestas (2)

Prefiero crear una nueva historia que luego vaya a la cartera de pedidos. La historia suele ser algo así como:

"Al usar [función que creamos en el sprint actual] quiero poder hacer [x]"

Tenga en cuenta que dije que va al backlog, y no necesariamente al siguiente sprint. Es algo nuevo y debe priorizarse frente a todo lo demás que ya está pendiente.

Las cosas nuevas son cosas nuevas que son cosas nuevas. Todos van al mismo lugar, sin importar cuándo se pensaron en ellos.

Estoy totalmente de acuerdo con los comentarios acerca de que esto va a la acumulación general. Las cosas en las que estás trabajando en este momento siempre parecen tener una mayor importancia que todo lo demás. Tienes que poner estas cosas en el backlog y luego volver a priorizar todo el backlog, no solo poner automáticamente estos nuevos elementos en el próximo sprint.
¿No debería la prioridad también tener en cuenta que la persona que trabaja en esto tendrá que dedicar tiempo a ponerse al día si pasa demasiado tiempo entre la implementación inicial y los nuevos cambios? Parece que este proceso podría sofocar el impulso.
No me parece. La prioridad debe basarse en las necesidades del propietario del producto, no en la conveniencia de los desarrolladores. La idea es entregar el software que quieren, no el software que es fácil de hacer para nosotros. Aunque yo diría que es algo para que el propietario del producto sea consciente.
@jmort253 El cambio de contexto puede afectar la estimación de puntos de la historia asignada durante la Planificación de Sprint, pero es independiente de la prioridad de una historia en la Lista de Producto.

Si estás siguiendo Scrum, entonces hay dos opciones:

  • El propietario del producto finaliza el sprint y las modificaciones se vuelven a evaluar y se crean nuevas historias de usuario.

  • Las nuevas ideas se convierten en historias de usuario para el próximo sprint

Además, sugiero una retrospectiva sobre el tema, porque ¿cómo es que las nuevas ideas no se conocen en la reunión de planificación? Parece que algo está cambiando o no está claro en segundo plano y debe solucionarse pronto.

Aunque sea tentador, no cambie la historia de un usuario comprometido. Te causará demasiados problemas y se activará el efecto de la ventana rota : habrá otro pequeño cambio, luego otro, otro... (y no existe tal cosa como un pequeño cambio)

+1 por hacer referencia al efecto de ventana rota, ya que describe perfectamente el problema de cambiar una historia de usuario comprometida.
Manejo de nuevas sugerencias para historias de usuario resueltas en sprint cerrado
RespuestasAquíPolítica de privacidad1y, 0v