Necesito un consejo y se trata de la mejor opción para elegir en un proyecto ágil, aquí está la situación:
¿Qué hacer? ¿Deberíamos crear un nuevo ticket en el próximo sprint, exactamente el mismo EE. UU., volver a estimarlo en quizás 5 puntos porque hicimos algún trabajo en él? y cerrar el que empezamos después de reestimarlo a 8 puntos?
¿O mantener los mismos 13 puntos en el próximo sprint a esta misma tarea?
En última instancia, depende del equipo, pero espero que dependa exactamente de cómo uses los puntos. Una regla que me gusta usar cuando una historia no está completa al 100% es contarla como cero puntos hacia la velocidad del sprint actual. Si eso es lo que hace, le sugiero que deje los puntos sin cambios cuando agregue la historia al próximo sprint. El efecto de eso será mostrar una caída en la velocidad en el sprint actual pero un aumento correspondiente en el próximo sprint, lo que parece tener sentido.
Si bien entiendo el argumento a favor del pragmatismo o de dejar que el equipo decida, le recomendaría absolutamente que lleve la misma historia de 13 puntos al próximo sprint. Scrum está destinado a entregar incrementos de producto, no a hacer trabajo. Eso puede parecer una declaración tonta porque ciertamente tiene que hacer el trabajo para entregar el incremento, pero se trata de dónde pone el foco.
Entonces, veamos la pregunta en esa lente. Si dividimos la historia, se trata de mostrar que se hizo el trabajo. Pero oculta el hecho de que no se entregó ningún incremento del producto. Por otro lado, transferir la historia solo marca la casilla de terminado una vez que se entrega el incremento, independientemente de dónde se haya realizado el trabajo. Entonces, ¿cuál cumple realmente con la intención de Scrum?
Ahora, hay una tercera respuesta matizada a esto. Digamos que nos quedan 2 días en el sprint y está claro que este elemento del backlog no se completará. Entonces, en ese momento, acordamos con el PO que podríamos entregar parte de la función en un estado potencialmente liberable (control de calidad, implementable, etc.) si no trabajamos en absoluto en otra parte y todos están de acuerdo en que esto tiene sentido comercial. . Ahora, hemos entregado parte de esa historia de 13 puntos y tiene sentido darlo por terminado y mover el resto al siguiente sprint. Entonces, podría volver a estimar ambas historias si eso le diera algún valor en el equipo.
No hay ninguna mejor opción; puedes hacerlo de cualquier manera. La mejor opción aquí es decidir esto junto con su equipo en lugar de tener una sola voz que diga "lo haremos de esta manera".
Así es como veo esto, otros pueden usar diferentes enfoques dependiendo de cómo usen la velocidad.
La velocidad es algo que debería mostrar el progreso por sprint, no el trabajo por sprint. Si divide los puntos de la historia, está midiendo el trabajo, no el progreso. La historia de usuario que está "Listo" significa progreso, la mitad no es realmente progreso porque en Agile el progreso se mide en el software en funcionamiento, no en el porcentaje de trabajo completado.
Entonces, si divide los puntos de la historia, su sprint actual mostrará más progreso del que realmente logró. Para pronósticos futuros, esto podría dar una visión más optimista de lo que puede hacer. Parece que hiciste más, pero de hecho algo se derramó en el siguiente sprint. Una velocidad más pequeña explicará el hecho de que esto puede ocurrir nuevamente en el futuro, por lo que hace que la medida de la velocidad esté más en sintonía con la realidad (al menos así es como yo lo veo).
En su próximo sprint, recalcula la historia de lo que aún queda por hacer y terminar este trabajo se reflejará en la velocidad de este próximo sprint como "Terminado".
En general, haces más o menos el mismo trabajo, pero la velocidad reflejará el "hipo" en este sprint.
nvogel
Sushi
nvogel