Cómo manejar tareas sobrantes en TFS

Question

¿Cuál es el mejor enfoque para manejar tareas e historias de usuarios que no finalizaron en Sprint TFS?

Mi enfoque:

• Conjunto todas las tareas de 'cerrado' con la razón correcta subestado. Copio esta tarea + estimación original + horas restantes a Bloc de notas.
• Retire la iteración de la historia de usuario (por lo que será la Cartera de pedidos del producto nuevo)

Para el siguiente sprint:

• Añadir las tareas de Bloc de notas para TFS como nuevas tareas, asignarlo a la historia del usuario correcto y establecer la historia del usuario para el sprint actual.

Este es solo un enfoque. ¿Tienes mejores ideas o sugerencias?

Answer 1

Si usted está realmente haciendo Scrum, verá la única métrica importante para cualquier equipo es "restante Trabajo". La cuestión es que muchas personas están obsesionadas con métricas, estadísticas, datos y pistas sueltas de la esencia de Scrum.

Así que manténgalo simple. En la revisión de sprint, simplemente acuerde con el PO cuándo completar el trabajo y luego asigne las tareas pendientes al sprint acordado.

Si desea un poco de un impulso de productividad; a continuación, cree una consulta de tareas deshechas y simplemente reemplace el valor de la columna de iteración por el siguiente sprint y publíquelo nuevamente en TFS.

Answer 2

Marcándolos cerrados, en mi opinión, no es necesario. Simplemente mantenga las tareas restantes, marque/etiquete como inacabadas, comience un nuevo sprint y aplique todas las tareas con esa bandera en particular como del sprint nuevo/próximo (y si es necesario, vuelva a evaluar sus tiempos y dificultades).

Answer 3

que hacemos exactamente lo mismo que lo hace, pero en lugar de utilizar el Bloc de notas, simplemente copy la tarea en una nueva & luego asignar esto en la nueva iteración. De forma predeterminada, la copia-Tarea está vinculada a todos los elementos de trabajo que tenía el original, así como a la tarea original.
La tarea anterior permanece en la iteración anterior & se marca como 'Cerrada'.

Answer 4

Hay dos escuelas de pensamiento:

1. dejar estos y crear otros nuevos en la iteración Pila de Producto (a menudo la raíz del equipo de proyecto). Los abandonaríamos y eliminaríamos los puntos (para el informe Velocity), ya que representan el plan de nuestro sprint.
2. Actualice la iteración a la cartera de pedidos del producto y trátelos como cualquier otra historia durante el próximo sprint. (Me suscribiría a este)

Cada equipo es diferente con las tareas. Si selecciona la historia nuevamente en el siguiente sprint, actualice la ruta de iteración de tareas y finalice. Si no lo recupera, eliminaría las tareas para que debata cómo cumplir con la necesidad en el contexto del software tal como existe cuando haga y recupérelo. Dejar las tareas en una historia por más de un sprint tiene una forma de darnos una falsa sensación de seguridad de que esas son todavía todas las cosas necesarias. Preferiría volver a evaluar cómo lo cumpliremos.

Answer 5

Quizás no entendí bien tu problema, pero esta es mi opinión: La idea principal de las tareas deshechas es que el backlogitem/userstory no está hecho. Entonces, después del sprint todos los backlogitems/userstories que se realizan -> nuevo incremento. Si un backlogitem no está totalmente listo, entonces no se entrega todo el backlogitem, incluso si solo quedan unas pocas tareas. Simplemente tira todo hacia atrás (guarda el código :)) y termina el sprint. El backlogitem/userstory va al siguiente sprint.

Answer 6

Es un escenario muy común, y tenemos algo en nuestra cartera de pedidos para crear una solución apta para este propósito, pero aún no hemos priorizado sobre otros trabajos.

Si usted piensa que esto es importante, siéntase libre de agregar la sugerencia al user voice. Utilizamos ese sitio en nuestra priorización: es su oportunidad de influir en nosotros

Ewald Hofman (TFS Product Group)