TL;DR: В целом идея скорее является просто сформулированной интуитивной эвристикой, чем каким-то монументальным подходом.

Задумался о “степенном” подходе приоритезации (читай сортировки) задач. Для задач можно использовать N очередей, где N - порядок выполнения и одновременно степень, в которую надо возвести число задач, которые исполнитель может выполнить за итерацию. Под исполнителем имею в виду отдельного человека, для нескольких/отдела подход нужно немного адаптировать.

Пример. Есть 30 задач в бэклоге и более менее за итерацию человек способен обработать 4шт.

  1. q0: 4^0 = 1 - задачи в работе в текущий момент. Что бы не говорили, а человек однопоточный.
  2. q1: 4^1 = 4 - задачи, которые планируется выполнить в ближайшее время, в этой итерации, которые в паузе из-за асинхронного I/O.
  3. q2: 4^2 = 16 - задачи, которые таки надо сделать как-нибудь и на которые можно давать какой-то прогноз в духе “ну, в ближайший месяц, наверное”.
  4. q3: 4^3 = оставшиеся 9 (но влезло бы 64). Задачи, которые просто лежат. Хрен знает когда они будут сделаны и будут ли, но идея прикольная.

Единственной причиной перемещения задачи из одной очереди в другую должно быть истощение предыдущей очереди. Отмена задачи извлекает её из всех очередей. Неприкосновенность очередей (как спринта в скраме) штука специфичная - с одной стороны да, разработчикам-аутистам с ней хорошо, никто не дёргает лишний раз, меньше разочарований из-за того что “блин, я только начал делать, можно уже определиться с тем, что мы делаем, а что нет?”, а с другой - отрицание реальности приведёт лишь к более позднему отбросу результатов деятельности (которых уже будет больше). В принципе компромисс, при котором добавление новой задачи в не самую последнюю очередь требует переноса другой задачи подальше - не самый плохой.

При этом подход масштабируется с ростом числа задач в бэклоге. Очередей становится больше, чем дальше - тем туманнее перспективы их реализации. N - тоже регулируемый параметр в зависимости от того насколько задачки мелко-нарезанные, а исполнитель - производительный. Опять же, прогнозирование без упорядочивания - дело такое себе, но можно оценивать начало и завершение выполнения всех задач в очереди. Можно и без оценок обойтись - если она не задана человеком, использовать среднее из уже выполненных.

Насчёт чем дальше - можно ещё и погрешность в оценке и сроках увеличивать в зависимости от того, в какой из очередей находится задача. В теории можно по-умолчанию считать погрешность оценки равной доле задач, находящихся в очереди от общего числа задач проекта.

Исполнителей можно огородить очередями q0, q1, q2, чтобы не отвлекались на остальное. Особо тревожных аутистов можно и q0/q1 ограничить. И тут появляется любопытный эффект. Если из q3+ не делать помойку и прибираться там раз в месяц, то многие задачи вообще будут отменены как неактуальные до того как о них вообще узнает исполнитель. Для этого нужно, чтобы у исполнителя был менеджер. Либо переключаться самому иногда в него и с помощью двоемыслия забывать о задачах из далёких очередей и возвращаться к текущим.