将需求分为必须有、应该有、可以有、这次不做四类，快速在团队内建立优先级共识，避免功能范围蔓延。
失败的 Sprint 和延期上线，最常见的根本原因是范围蔓延——那些看起来「只要加一下」的功能，不断积累，直到没有任何东西能按时交付。
范围蔓延的背后是一个更深层的问题：团队回避了那个最难的问题——「如果这个功能没做，会怎样？」当所有人都说「这个也很重要」时，实际上没有任何东西是真正重要的。
MoSCoW 强制团队回答这个问题。它不只是分级——它要求每个需求都经过「如果不做这个，产品是否无法运作/交付价值」的审视。这个问题很难回答，但它是所有优先级工作的核心。
MoSCoW 把所有需求分入四个桶。字母中的小写 o 只是为了拼写成可记忆的单词，不代表任何类别。
MoSCoW 在任何需要在约束条件下做取舍的场合都能发挥作用——时间约束、资源约束或战略约束。
2011 年，玛莎·莱恩·福克斯的报告呼吁英国政府对数字服务进行根本性重构。政府数字服务（GDS）团队面临一个令人窒息的任务：将 650 多个分散的政府网站整合为一个统一的平台。
历史上，英国政府 IT 项目平均需要数年，预算超支，功能臃肿。GDS 团队决定采用完全不同的方式——用 MoSCoW 对需求进行严苛的分层，只做真正必须做的事。
MoSCoW 看起来只是给需求贴标签，但在实践中，它的有效性完全取决于执行质量。以下是最常见的陷阱和对应方法。
MoSCoW 方法诞生于 1990 年代英国敏捷运动的前沿，由甲骨文 UK 的软件开发顾问 Dai Clegg 在 DSDM（动态系统开发方法）中首次提出，以一种简单到极致的四桶分类，帮助团队在时间箱压力下做出清晰的范围决策。这套方法从英国金融和政府项目出发，随着敏捷浪潮席卷全球，成为产品经理、项目经理和业务分析师共同的优先级通用语言。