Любой фреймворк приоритизации выглядит безупречно на слайде и разваливается при первом столкновении с реальным бэклогом из 80 кое-как описанных задач. Дело не в том, что фреймворки неправильные — просто их перестают применять уже на второй неделе.

Решение не в более сложном фреймворке. Решение — в простом, который вы реально будете использовать.

Четырёх критериев достаточно

Команды часто переусложняют приоритизацию семимерными скоринговыми таблицами, заполнение которых занимает дольше, чем сама задача. Почти любое реальное решение покрывают четыре критерия:

  • Влияние — насколько это двигает результат, который вас реально интересует.
  • Трудоёмкость — приблизительный размер, а не точная оценка. Маленькая / средняя / большая — достаточно.
  • Срочность — стоит ли что-то ожидание, или задача может лежать месяц без последствий.
  • Зависимости — блокирует ли что-то эту задачу, или она блокирует что-то другое.

Оцените каждый критерий от 1 до 3, умножьте влияние на срочность, разделите на трудоёмкость и отсортируйте. Не нужен макрос в таблице — нужно правило, которое все применяют одинаково.

Зависимости важнее влияния чаще, чем кажется

Команды часто ранжируют только по влиянию и трудоёмкости — а потом натыкаются на задачу с низким влиянием, которая тайно блокировала три важных задачи. Если задача разблокирует другие, её приоритет на самом деле не 1–3 — он наследует приоритет всего, что от неё зависит. Это самая частая причина, по которой "объективно приоритизированный" бэклог всё равно даёт неправильный порядок работы.

Именно поэтому приоритизация — это задача про граф, а не про список: важно видеть, что с чем связано, а не просто отсортированный столбец баллов.

Пересчитывайте приоритеты по графику, а не когда уже поздно

Балл приоритета — это снимок того, что вы знали в момент его выставления. Новая информация (эскалация от клиента, зависимость, оказавшаяся сложнее, чем думали) тихо обесценивает старые баллы. Пересчёт верхней части бэклога раз в одну-две недели ловит расхождение до того, как оно превращается в пожар.

Держите балл рядом с задачей, а не в отдельном документе

Если баллы приоритизации живут в таблице, отдельной от того, где реально отслеживаются задачи, они сгнивают за один спринт — никто не обновляет документ, который не открывает каждый день. Привязка приоритета, влияния, трудоёмкости и зависимостей прямо к задаче, на той же доске, где меняются статусы, — то, что держит фреймворк живым, а не разовым упражнением.