Как не утонуть в бэклоге
Когда бэклог раздувается и сроки поджимают, начинается борьба за внимание — каждая задача кажется важной. В спринт пытаются запихнуть как можно больше задач, потому что сроки. В итоге каждый спринт заканчивается переносом большей части задач в новый, и к ним добавляются еще задачи. В таких случаях для исправления ситуации можно предпринимать множество различных шагов, один из которых — приоритизация бэклога. Один из них — метод MoSCoW.
Что такое MoSCoW?
MoSCoW — это аббревиатура, которая расшифровывается как:
- Must have (Должно быть)
- Should have (Следует иметь)
- Could have (Может быть)
- Won't have (Не будет)
Это интуитивно понятная техника, которая позволяет быстро классифицировать требования к продукту или проекту, основываясь на их критичности и ценности. Она идеально подходит для любого этапа разработки и помогает всей команде, от стейкхолдеров до инженеров, выработать общее понимание приоритетов.
🔧 Как использовать MoSCoW на практике
Формируем список задач
Необходимо собрать всё, что обсуждали с командой, бизнесом и пользователями. Это могут быть фичи, баги, технический долг, гипотезы.
Оцениваем каждую задачу по критериям
Must have
- Без этой задачи релиз или продукт не имеет смысла или будет сломан.
- Юридические, технические, архитектурные обязательства.
- Примеры: авторизация, платеж, интеграция с критичным API.
Should have
- Важные задачи, но не критичные задачи.
- Если не сделать — будет больно, но можно временно пережить.
- Примеры: фильтрация в списке, экспорт в Excel.
Could have
- Хорошо бы иметь, но при нехватке ресурсов легко отбросить.
- Повышают удобство, UX, добавляют “вау”-эффект.
- Примеры: анимации, автозаполнение, тёмная тема.
Won't have (Не сейчас)
- Сейчас не приоритет, можно сделать позже.
- Явно зафиксировано, чтобы избежать спорных ожиданий.
- Примеры: кастомные графики, локализация.
Не нужно бояться ставить задачи в «Won’t-have» — это не отказ, а стратегическое откладывание. Главное — коммуницировать причины команде и заказчикам.
Планируем итерацию
При формировании спринта/релиза:
- Сначала берем Must have
- Затем — Should have, если есть ресурсы
- Could have — по остаточному принципу
- Won’t have — в отдельный backlog
Можно договориться и установить примерные лимиты на приоритеты, которые пойдут в итерацию — например, MUST: 60%, SHOULD: 20%, COULD: 20%. Это предотвратит "раздувание" MUST. Визуализируем — создаем доску с категориями (Miro, Jira) или отмечаем в бэклоге.
Регулярно обновляем приоритеты
Рынок, требования, гипотезы — всё меняется. Регулярная переприоритизация — это нормальная практика. Запланируйте регулярные активности по анализу бэклога.
Используйте MoSCoW, чтобы трансформировать бэклог из пугающего списка задач в четкий управляемый план действий.
Подпишись на мой канал в telegram