Почему Must должен быть ≤ 60% от capacity?

Если Must занимает > 60% ёмкости спринта/релиза, команда не имеет буфера на непредвиденные задачи, технический долг и Should-фичи. Практика показывает: реальные оценки занижены в среднем на 30-50%, поэтому закладывать 100% на Must - гарантия срыва сроков. Лимит 60% - это защитный буфер.

Чем MoSCoW отличается от WSJF и RICE?

MoSCoW - категориальный метод: фичи делятся на 4 группы, фокус на обязательности. WSJF (Weighted Shortest Job First) - числовой: считает соотношение ценности к длительности, хорош для SAFe. RICE (Reach × Impact × Confidence ÷ Effort) - тоже числовой, учитывает охват и уверенность. MoSCoW быстрее и понятнее стейкхолдерам, WSJF/RICE точнее при большом количестве однотипных задач.

Что значит Won't have this time - это навсегда?

Нет. Won't have this time означает «не в текущем релизе/спринте/квартале». Это честный способ сказать команде и стейкхолдерам: мы видим эту задачу, но осознанно не берём её сейчас. В следующем планировании фича может перейти в Could или даже Must. Главное - фиксировать причину, чтобы не объяснять заново.

Как часто нужно пересматривать MoSCoW-список?

Для спринтов (1-2 недели) - каждый спринт. Для квартального планирования - каждые 6-8 недель или после значимых изменений: новые данные от пользователей, смена стратегии, изменение рынка. Статичный MoSCoW теряет актуальность быстро - это живой артефакт, а не документ «написал и забыл».

Что делать, если Must > 60% и нельзя двигаться?

Есть три пути: 1) Разбить Must-задачи - часто «обязательная» фича содержит optional-части, которые можно перевести в Should. 2) Увеличить capacity - дополнительный разработчик, сокращение совещаний, снижение WIP. 3) Пересмотреть Must - честно спросить: что реально произойдёт, если этого не будет в этом релизе? Иногда Must оказывается Should.

Можно ли использовать MoSCoW без оценки в часах?

Да, MoSCoW работает и без цифр - просто как категоризация. Но добавление трудозатрат делает метод количественным: вы видите, сколько % capacity уходит на Must, и можете обоснованно защищать приоритеты перед бизнесом. Калькулятор выше реализует именно этот усиленный вариант.

Приоритизация продукта

MoSCoW приоритизация онлайн

Распределите фичи по категориям Must / Should / Could / Won't, задайте оценку в часах и проверьте загрузку по правилу «Must ≤ 60% capacity» через светофор.

MoSCoW помогает продуктовым командам быстро договориться о приоритетах и защитить буфер от непредвиденных задач. Метод активно используется в Agile и DSDM.

Расчёт в браузере
Данные не сохраняются
Светофор Must ≤ 60%
4 категории M/S/C/W

Открыть калькуляторОценки ориентировочные - используйте как инструмент обсуждения.

Категории MoSCoW

Must have

Обязательно

Should have

Нужно

Could have

Желательно

Won't have

Не в этот раз

Правило: Must ≤ 60% capacity - защитный буфер от срыва сроков.

Быстрое согласование

MoSCoW - самый быстрый способ договориться о приоритетах. Четыре категории понятны всем: разработчикам, дизайнерам и стейкхолдерам.

Контроль перегруза

Правило Must ≤ 60% защищает команду от нереалистичных планов. Если Must > 60%, нужно сократить список или увеличить capacity.

Живой артефакт

MoSCoW-список пересматривается каждый спринт или квартал. Won't have this time - не навсегда, а сознательное решение «не сейчас».

Калькулятор MoSCoW

Добавьте фичи, выберите категорию, укажите трудозатраты. Светофор обновляется в реальном времени.

Бюджет capacity (часов на спринт/релиз)

Например: 80 ч = 2 разработчика × 2 недели × 50% полезного времени

Must have занимает 20.0% capacity - хороший запас, есть место для Should и Could.

Must: 16.0 ч · Capacity: 80 ч · 20.0% загрузки

Распределение часов по категориям

M (Обязательно)

16.0 ч (20%)

S (Нужно)

12.0 ч (15%)

C (Желательно)

8.0 ч (10%)

W (Не в этот раз)

20.0 ч (25%)

Всего часов

56.0 ч

Сумма по всем категориям

Загрузка capacity

70%

Всего / capacity

Must have

16.0 ч

Обязательные задачи

Should + Could

20.0 ч

Важные и желательные

Сохранить или обсудить

PDF собирается в браузере - мы не сохраняем ваши данные. Письмо открывается в вашем почтовом клиенте - вы сами решаете, что отправить.

Обсудить с экспертом

Список фич (4)

Добавить фичу

Данные хранятся только в браузере, не передаются на сервер. Расчёты носят ориентировочный характер.

Числовой пример: спринт 80 часов

Команда из двух разработчиков, спринт 2 недели. Полезная производительность ~80 ч.

Определяем Must

Авторизация (16 ч) + Платёж (20 ч) = 36 ч Must → 45% capacity ✓

Should-задачи

Профиль пользователя (12 ч) + Уведомления (8 ч) = 20 ч → 25%

Could-задачи

Тёмная тема (8 ч) → 10% capacity, берём при наличии времени

Won't this time

Интеграция со Slack (20 ч) - откладываем на следующий спринт

Итог загрузки

36 + 20 + 8 = 64 ч (80%) - буфер 16 ч на hotfixes и ревью

Вывод: Must = 45% capacity - жёлтая зона, нормально. Буфер 20 ч (~25%) защищает от задержек. Если добавить ещё один Must, сразу попадаем в красную зону → нужно что-то убирать.

Детально о каждой категории

Правильная классификация - самый важный шаг. Команды часто переоценивают Must.

MMust have

Когда ставить

Продукт не работает без этой фичи
Юридическое или compliance-требование
Критический баг в production
Базовая функция, без которой пользователь уйдёт

⚠️ Не путайте Must с «очень хочется» - это ловушка scope creep.

SShould have

Когда ставить

Важно, но есть временный workaround
Улучшает опыт без блокировки использования
Стейкхолдеры ждут, но не критично для релиза
Следующая по приоритету после Must

⚠️ Should должны войти в релиз при любых обстоятельствах - это не «может быть».

CCould have

Когда ставить

Приятное дополнение при наличии времени
Небольшой wow-эффект для пользователей
Улучшение метрик, но не критичное
Можно сделать в конце спринта из буфера

⚠️ Could часто не попадает в релиз - и это нормально. Не обещайте их стейкхолдерам.

WWon't have

Когда ставить

Интересно, но не сейчас
Нет данных, что пользователи это хотят
Большой объём при низком приоритете
Зависит от других фич, которых ещё нет

⚠️ Won't ≠ никогда. Фиксируйте причину отказа, чтобы вернуться к фиче позже.

Правило светофора: Must и capacity

Калькулятор оценивает долю Must от общей capacity и выдаёт сигнал.

Зелёный - Must < 40% capacity

Отличный запас. Команда спокойно возьмёт Should-задачи и часть Could. Есть буфер на технический долг и непредвиденные задачи.

→ Проверьте, не перенесли ли вы что-то важное в Should/Could.

Жёлтый - Must 40-60% capacity

Рабочая зона. Must под контролем, Should войдут в спринт. Небольшой буфер есть, но нет пространства для экспериментов.

→ Это целевое состояние для большинства команд.

Красный - Must > 60% capacity

Перегруз. Команда, скорее всего, не успеет даже Must. Should и Could не войдут. Риск срыва сроков очень высок.

→ Разбейте Must на части, пересмотрите классификацию или увеличьте capacity.

Частые вопросы о MoSCoW

Ответы на популярные вопросы о методе и калькуляторе.

M - Must have (обязательно): без этого продукт не работает или не выходит. S - Should have (нужно): важно, но есть workaround. C - Could have (хорошо бы): желательно при наличии времени. W - Won't have this time (не в этот раз): сознательно откладывается, но не навсегда.