产品待办事项列表是一个核心工件，它整合了与产品相关的所有信息，例如需求、估计、沟通、进度状态等。在瀑布管理中，它被称为票证、问题或任务。产品待办事项列表由四层层次组成：主题、史诗、用户故事和任务。
主题代表了跨越数月或数年的长期产品战略。
Epic 具有巨大的价值，影响商业投资，并且需要几个月的冲刺才能完成。
用户故事是每个 Sprint 中必须交付的小价值。
任务是可以在几天内完成的用户故事的细分。
用户故事
用户故事应该包含三个基本元素来阐明需求：用户故事（句子）、 99 英亩数据库 验收标准和视觉图像。用户故事（短语）描述了用户希望通过产品实现什么目标，包括谁、什么和为什么。下面是一个示例。
作为用户（谁），我希望通过邮箱地址和密码（什么）登录平台，以便可以安全地使用平台（为什么）。
视觉图像可以是草图、原型或支持共同理解和激发对话的复杂设计。由于用户故事和验收标准是基于文本的表达，视觉图像可以帮助人们想象软件应该如何运行。
接受标准是什么？
验收标准是敏捷实践之一，用于有效地编写完成之前必须满足的需求，简而言之，它就是定义需求和功能的用户故事。
由于需求定义是软件开发中最困难和最耗时的过程，因此 Agile 创建了一种有效且高效的编写需求的方法。验收标准不仅用于需求，也用于验收测试，因此开发团队不必分别编写两者。
虽然编写验收标准有多种格式，但由 Cucumber 创始人 Aslak Hellesøy 创建的 Gherkin Syntax 可能是理想的选择之一，因为它是最全面的格式之一。 Gherkin 的语法由四个简单元素组成：场景、给定、何时和然后，它们描述了软件应如何运行。该框架全面涵盖了软件行为的所有必要方面，适合定义详细需求。您可以在下面看到每个元素的解释和示例。
用户故事范围管理的上下文
用户故事应该足够小以便在一个 Sprint 内完成，从而实现一致的、迭代的交付。因此，管理用户故事的范围至关重要，因为范围对估算有很大影响。依据不确定性锥，研究开发阶段与估算精度的关系，得出明确的需求与范围对估算精度的提高最为显著。 “范围蔓延”现象（也称为需求蔓延或厨房水槽综合症）也表明，如果开发团队在编码之前没有明确需求和范围，范围就会随着开发的进展而扩大。
Construx：不确定性锥体
另一个考虑因素是项目管理三角，它描述了影响决策过程的三个约束（范围、成本和时间）。由于项目资源总是有限的，因此我们必须做出明智的决策。
项目管理三角
这里的关键点是，范围管理在敏捷中比在瀑布中更为重要。在敏捷中，资源和时间是固定的，而范围是灵活的。由于 Agile 旨在实现快速、迭代交付，因此产品经理会考虑如何在有限的时间和资源下最大化产品的价值。如果范围太大而无法在计划时间内完成，则应通过优先排序来缩小范围。相比之下，瀑布模型的范围是固定的，而资源和时间是灵活的。
敏捷与敏捷铁三角项目管理。
基于这些研究和实践，用户故事管理的一般流程（背景）如下。
通过用户故事、验收标准和视觉图像澄清需求。
根据验收标准讨论范围。没有需求就无法管理范围。这一步和需求定义通常一起完成。这就是我认为 MoSCoW 方法非常有用的地方。
用户故事是根据其范围进行估算的。正如我之前提到的，明确的要求和范围对估算准确性贡献最大。如果用户故事太大，则应该将一些需求拆分成其他用户故事，以便稍后进行管理。
最终决定取决于要求、范围和估计。它通常在 Agile 中的 Sprint Planning 中确定。