用户故事应该足够小以便在一个 Sprint 内完成，从而实现一致的、迭代的交付。因此，管理用户故事的范围至关重要，因为范围对估算有很大影响。依据不确定性锥，研究开发阶段与估算精度的关系，得出明确的需求与范围对估算精度的提高最为显著。 “范围蔓延”现象（也称为需求蔓延或厨房水槽综合症）也表明，如果开发团队在编码之前没有明确需求和范围，范围就会随着开发的进展而扩大。
Construx：不确定性锥体
另一个考虑因素是项目管理三角，它描述了影响决策过程的三个约束（范围、成本和时间）。由于项目资源总是有限的，因此我们必须做出明智的决策。
项目管理三角
这里的关键点是，范围管理在敏捷中比在瀑布中更为重要。在敏捷中， 99 英亩数据库 资源和时间是固定的，而范围是灵活的。由于 Agile 旨在实现快速、迭代交付，因此产品经理会考虑如何在有限的时间和资源下最大化产品的价值。如果范围太大而无法在计划时间内完成，则应通过优先排序来缩小范围。相比之下，瀑布模型的范围是固定的，而资源和时间是灵活的。
敏捷与敏捷铁三角项目管理。
基于这些研究和实践，用户故事管理的一般流程（背景）如下。
通过用户故事、验收标准和视觉图像澄清需求。
根据验收标准讨论范围。没有需求就无法管理范围。这一步和需求定义通常一起完成。这就是我认为 MoSCoW 方法非常有用的地方。
用户故事是根据其范围进行估算的。正如我之前提到的，明确的要求和范围对估算准确性贡献最大。如果用户故事太大，则应该将一些需求拆分成其他用户故事，以便稍后进行管理。
最终决定取决于要求、范围和估计。它通常在 Agile 中的 Sprint Planning 中确定。
什么是 MoSCoW？
MoSCoW（必须拥有，应该拥有，可以拥有，不会拥有）是由 Dai Clegg 于 1994 年开发的一种优先级排序方法，用于快速应用程序开发 (RAD)。它于 2002 年首次与动态系统开发方法 (DSDM) 一起被广泛使用。MoSCoW 将需求分为四个类别：必须具备、应该具备、可以具备和不会具备。
必須有：必須實施要求。如果未能实施，这些功能将无法使用，并且交付将被视为失败。 MUST 也被认为是“最小可用子集”的首字母缩写。
应该具备：要求不像“必须具备”要求那么重要，但必须实施。尽管功能可以在没有要求的情况下使用，但它们通常是为了满足客户满意度而实现的。
可以：要求改善 UI/UX，从而提高客户满意度。它们通常在时间和成本允许的情况下实施。
不会有：目前不需要这些要求，可能会稍后考虑。
用户故事和 MoSCoW 的示例
我们通过一个示例了解如何使用验收标准和 MoSCoW。为了简单起见，我将使用以下登录图像。
示例登录表单
写下您能想到的所有验收标准。我将使用以下四个场景作为例子。
编写验收标准（用户故事）后，将每个场景分类为 MoSCoW 类别，如下所示。然后，决定你愿意开发到什么程度，最好专注于必须具备的功能来定义最小可行产品（MVP）。在下面的例子中，“必须具备”和“应该具备”在范围内，而“可以具备”和“不会具备”超出范围，将在不同的用户故事中开发。