Primero, haga que cada desarrollador mire cada uno de los elementos y revise / pruebe cada elemento para ver si todavía es un problema (puede funcionar mejor dividirlos entre las personas). Luego, cierre cualquiera que ya no sea un problema o que ya haya sido atendido con otros esfuerzos de desarrollo.
Ahora asegúrese de que cada uno esté marcado como un esfuerzo de desarrollo grande, mediano o pequeño. Esta es una estimación muy aproximada que se utiliza para clasificar más fácilmente los proyectos y para ayudar a unir las cosas. Si todo ya está estimado, entonces ayudará, pero no te obsesiones con las horas. Solo ve con un rápido control intestinal. A menudo funciona para poner a los desarrolladores en una habitación y solo revisar cada elemento y usar el esfuerzo que la mayoría de las personas siente que es apropiado.
Revise cada uno de los tres grupos de esfuerzo y marque cada elemento en el grupo con una prioridad de Crítico, Alto valor comercial, Alto valor técnico, Valor medio, Valor bajo y Nunca se va a arreglar.
En este punto, usted realmente conoce la lista de adentro hacia afuera y realmente comprende el trabajo que implica su trabajo atrasado y puede comenzar a tomar una decisión sobre qué hacer con los elementos. Tome todos los elementos marcados como que nunca se van a arreglar y archívelos fuera de su cartera de pedidos.
Ahora, cuando programe los elementos para su próxima versión, puede utilizar los elementos críticos y de gran importancia como el núcleo de su versión. Revise la lista de elementos de prioridad media y baja y agregue cualquiera que se pueda trabajar al mismo tiempo que los otros elementos de su lista porque los desarrolladores ya estarán trabajando en esa parte del sistema.
La lista de elementos marcados con prioridad media o baja se puede usar como una lista de cosas para que las personas trabajen cuando tienen un poco de tiempo libre o como capacitación para nuevos empleados. Siempre encuentro que es bueno tener una persona en el equipo durante cada iteración trabajando en estos elementos y ayudando al resto del equipo cuando sea necesario. De esta manera, aún está completando el trabajo en la iteración actual, pero tiene a alguien que es flexible y puede ayudar a apagar incendios cuando sea necesario, pero está manejando los problemas que normalmente no llamarían la atención.
Una cosa que encontramos agradable fue que, entre cada iteración, tuvimos un corto período de 2 semanas en el que todo el equipo solo trabajaría en los elementos marcados con un pequeño esfuerzo de desarrollo. Nos enfocaríamos en cerrar una gran cantidad de boletos en poco tiempo.