足够的细节是通常的反应。
在我们目前正忙于的项目中（该项目不完整并且在没有任何类型的 brs/文档/用户故事的情况下移交给我们，我们得到的故事如下：
作为产品负责人，我需要 开发人员测试 XXX 工作流程，所以 它工作正常。
和
作为产品负责人，我需要 开发人员测试 YYY 工作流程，所以 它工作正常。
没有说明“正确”是什么意思。
当要求更多细节时，会被告知您要求的细节太多，因为这是敏捷的，所以在 sprint（2 周 sprint）的后期需求会变得更加清晰，此时您不必担心细节，而是只是在“娃娃毛”中赋予故事一个重量，并停止困难。做一个大人物。不用担心细节。
这就是敏捷该有的样子吗？
【问题讨论】：
标签： agile scrum requirements
当要求更多细节时，会被告知您要求的细节太多，因为这是敏捷的，所以在 sprint（2 周 sprint）的后期需求会变得更加清晰，此时您不必担心细节，而是只是在“娃娃毛”中赋予故事重量，并停止困难。做一个大人物。不用担心细节。
不是真的。用户故事抓住了本质，但这并不意味着没有细节。细节是在对话过程中传递的，绝对是强制性，以便更好地理解必须做什么（更不用说如果你不知道要做什么和预期什么，似乎很难估计任何事情） ）。
传达有关故事的详细信息实际上是产品负责人 (PO) 工作的一部分。这应该发生在 Sprint 计划会议的第一部分，PO 向团队解释每个故事，在计划扑克之前和/或任何需要澄清的时候。换句话说，请随时向 PO 询问详细信息（也向 PO 询问接受标准）。如果不确定性太大，请在故事前面放一个大估计，并解释为什么你不能做出“更好”的估计。
对我来说，您的 PO/客户/利益相关者似乎并没有非常积极地参与，这是一个非常非常大的障碍。你的 ScrumMaster 需要解决这个问题，没有神奇的解决方案。
【讨论】：
您应该尽可能多地询问细节，以便对故事进行评估。
您可以在故事卡的背面添加一些验收测试标准（这些不必详细说明）。
作为我想与之付款的客户 信用卡...
使用 Visa、MasterCard 进行测试
顺便说一句，你的故事似乎有点奇怪。他们应该以客户/功能为中心。
【讨论】：
Scrum 待办事项/用户故事无需非常具体即可添加到待办事项中。
需要更多详细信息才能使它们可冲刺（可在冲刺中安排）。那时需要足够的细节以便进行估算，并且应该有一个明确定义的完成标准。
User Story is a promise for a conversation 与产品负责人讨论其涵盖的场景。
过早的细节是一种浪费。
【讨论】：
您似乎在这里使用用户故事来定义流程，而不是系统中的功能。但我认为这里没有足够的细节让开发者知道测试是否通过。
此外，您在此处列出的是验收标准，用户故事通常更具描述性，并以一个或多个验收标准为基础，以定义功能的本质。
我会立即回到采购订单的问题是： Workflow XXX 的逻辑是什么？ 每一步都有哪些选择？ 记录了哪些（如果有）操作？ 发送哪些电子邮件/通知？如何？给谁？
如果产品负责人不能清楚地表达产品并且正在告诉 Scrum Master 敏捷是如何工作的，那么他可能需要“培训”。
尝试提供一个空白屏幕并询问他缺少什么。
【讨论】：
公司通常会采用混合流程策略。话虽这么说，这似乎是 rad（快速应用程序开发）+ scrum。如果这只是第一个 sprint，那么是的，这已经足够详细了。在第一个 sprint 的这一点上，我建议团队继续前进，确保工作流可以从头到尾执行，而不管它产生的结果如何。这通常意味着进行一些 Pokemon 异常处理（捕获异常而不是特定异常）、记录错误并将信息带入下一个 sprint。
【讨论】：
它需要从头到尾描述最简单的路径。它不需要描述所有的例外或变化。当您遇到这些例外和变化时，您需要与客户进行对话并根据需要更新故事。
【讨论】：
多少细节是“足够的”取决于很多事情。您的环境似乎表明需要更多细节。
首先，如果
【讨论】：