Во-первых, пусть каждый разработчик рассмотрит каждый из элементов и проверит / протестирует каждый элемент, чтобы убедиться, что он все еще остается проблемой (лучше всего поделить их между людьми). Затем закройте все, что больше не является проблемой или уже решено с другими усилиями по развитию.
Теперь убедитесь, что каждый из них помечен как большой, средний или маленький усилия по разработке. Это очень приблизительная оценка, которая используется для упрощения категоризации проектов и помогает объединить усилия. Если все уже оценено, то это поможет, но не зацикливайтесь на часах. Просто сделайте быструю проверку кишечника. Часто бывает так, что разработчики попадают в комнату и просто просматривают каждый элемент и прикладывают усилия, которые большинство людей считают целесообразными.
Просмотрите каждую из трех групп усилий и отметьте каждый элемент в группе с приоритетом Критический, Высокая ценность для бизнеса, Высокая техническая ценность, Среднее значение, Низкая стоимость и Никогда не собираюсь исправлять.
К этому моменту вы действительно знаете список наизнанку и действительно понимаете работу, которая связана с вашим бэклогом, и вы можете действительно принять решение о том, что делать с элементами. Возьмите все элементы, которые помечены как не подлежащие исправлению, и заархивируйте их из своего журнала.
Теперь, когда вы планируете, что элементы войдут в ваш следующий выпуск, вы можете использовать критические и важные элементы в качестве ядра вашего выпуска. Просмотрите список элементов со средним и низким приоритетом и добавьте любые, над которыми можно работать одновременно с другими элементами в вашем списке, поскольку разработчики уже будут работать в этой части системы.
Список предметов, помеченных со средним или низким приоритетом, может использоваться как список вещей, над которыми люди могут работать, когда у них есть немного свободного времени, или как обучение для новых сотрудников. Я всегда нахожу, что во время каждой итерации приятно, чтобы в команде был один человек, который помогал остальной части команды, где это необходимо. Таким образом, вы все еще завершаете работу над текущей итерацией, но у вас есть кто-то, кто обладает гибкостью и может помочь при тушении пожаров, когда это необходимо, но занимается проблемами, которые обычно не привлекают внимания.
Приятно было то, что между каждой итерацией у нас был короткий двухнедельный период, когда вся команда работала только над элементами, отмеченными небольшим усилием по разработке. Мы бы сфокусировались на закрытии большого количества билетов в короткие сроки.