在敏捷/Scrum 用户故事中，多少细节才足够？ [关闭]

通常的反应是足够详细就足够了。

在我们目前正在忙的项目中（该项目不完整并且在没有任何类型的 brs/文档/用户故事的情况下移交给我们，我们得到的故事如下：

作为产品负责人，我需要 开发人员测试 XXX 工作流程，以便 它工作正常。

and

作为产品负责人，我需要 开发人员测试 YYY 工作流程，以便 它工作正常。

没有说明“正确”的含义。

当要求更多细节时，人们会被告知您要求太多细节，并且由于这是敏捷的，因此在稍后的冲刺（2周冲刺）期间，需求将变得更加清晰，此时您不应该担心细节，而应该担心只是给故事赋予“娃娃毛发”的重量，并且不再变得困难。做一个有大局观的人。不用担心细节。

这就是敏捷应该有的样子吗？

当要求更多细节时，人们会被告知您要求太多细节，并且由于这是敏捷的，因此在稍后的冲刺（2周冲刺）期间，需求将变得更加清晰，此时您不应该担心细节，而应该担心只是给故事赋予“娃娃毛发”的重量，并且不再变得困难。做一个有大局观的人。不用担心细节。

并不真地。用户故事抓住了本质，但这并不意味着没有细节。详细信息在对话过程中传输，并且绝对是强制的为了更好地理解必须做什么（甚至更不用说，如果你不知道要做什么和期望什么，似乎很难估计任何事情）。

传达故事的细节实际上是产品负责人 (PO) 工作的一部分。这应该发生在 Sprint 计划会议的第一部分，PO 向团队解释每个故事，在计划扑克之前和/或在需要任何澄清时的任何时间。换句话说，请随时向 PO 询问详细信息（并向 PO 询问验收标准）。如果存在太多不确定性，请在故事前面进行一个大的估计，并解释为什么你不能做出“更好”的估计。

对我来说，您的采购订单/客户/利益相关者似乎并没有非常积极地参与，这是一个非常非常大的障碍。你的 ScrumMaster 需要处理这个问题，没有神奇的解决方案。