☀Объяснение:

Что такое MoSCoW?

Это метод приоритизации требований, где каждая фича относится к одной из категорий:
Must have – критически важно, без этого релиз не имеет смысла (обычно не более 40–50% от общего объёма).
Should have – очень важно, но может быть заменено обходным путём или реализовано позже.
Could have – желательно, но не критично (если время позволяет).
Won’t have – явное исключение (договорённость, что эта фича не делается в текущем релизе).

Как помогает MoSCoW?
Заказчик сначала относит все 20 фич к категориям. После обсуждения часто выясняется, что реальных Must have всего 5–6. Остальные переносятся на следующие версии. MoSCoW даёт заказчику инструмент осознанного выбора: если он настаивает на 10 Must have, команда показывает, что это физически не укладывается в сроки, и предлагает согласовать «жертвы».

Почему не другие варианты:
A (WSJF) – требует численной оценки ценности и длительности, хорошо для ранжирования бэклога, но менее нагляден для переговоров о границах релиза.
C (голосование) – не структурирован, ведёт к усреднению, а не к жёсткому отбору.
D (story points) – это оценка трудоёмкости, а не приоритизация бизнес-ценности.
Реальный кейс: В разработке мобильного приложения заказчик хотел 15 фич в первом релизе. Аналитик провёл MoSCoW-сессию, и в Must попало 6 фич. Остальные перенесли на второй релиз. Релиз вышел в срок, а второй релиз был доработан позже.

Что должен зафиксировать аналитик:
Регламент: «Каждое требование классифицируется по MoSCoW перед планированием релиза».
Критерии для Must have: если фича не выполнена, релиз не выпускается.
Процесс пересмотра: если появляется новая Must have, другая Must have должна быть перемещена в Should или Could (правило «вход только через выход»).

Вывод: MoSCoW – простой и эффективный способ приоритизации, особенно на этапе согласования границ релиза с бизнесом.