您不能仅以某种方式拥有用户故事，程序的功能必须记录在案。你最终会得到一份带有 scrum 的规范文档吗？如果你这样做了，你最终会分配时间来完成这项任务吗？
一个例子是复杂的工作流程。
另一个例子是加入团队的新成员。
【问题讨论】：
标签： scrum
这个问题会有很多好的想法。我的亲身经历告诉我：
1~ 工作产品本身就是一种文档形式：假设产品被接受，那么询问它在特定条件下应该做什么就相当于询问它在这些条件下实际做什么——登录并尝试获取你的答案。
2~ 测试，无论是手动的还是自动的（或混合的），都是一种文档形式。当然，单元测试可能与技术水平较低的团队成员（例如：“业务专家”或客户）所说的领域语言相去甚远。验收测试可能更接近某种“中间立场”。绝对 BDD 风格的测试似乎最有可能构建一种每个人都能理解的无处不在的语言（请参阅这方面的 Gojko's Bridging the Communication Gap）。尽管如此，所有这些形式的测试都是一种文档形式，可用于确定产品应该做什么。
3~ 根据您的项目在范围内的位置，您的文档（通常还有所有辅助工件）可能需要更高或更低程度的仪式。较小的产品，较小的团队，对上市时间至关重要的地方可能会发现，与它所增加的价值相比，非常正式的需求文档成本太高了。另一方面，跨越多个团队和多年开发的超大型项目会发现正式文档的投资回报率完全不同。
4~ 在完美的世界中，我们可能不需要以工作代码（在象牙塔中也是不言自明的）和测试（主要用于回归测试和- 在边缘 - 推动新功能的开发）。因此，需求文档的问题是关于完美世界/象牙塔和现实世界/战壕之间有什么不同的问题。当然，答案因项目和团队而异。例如，我们可以说“所有需求都应保存在此 wiki 中，并非常小心地维护，等等……”但如果团队对 wiki 不熟悉和不熟悉，这将行不通。
5~ 最后，利益相关者是您应该询问的人。当然，应该以协作的方式处理该主题，因为团队中的每个人都必须在整个项目中与需求进行交互，但您必须找到满足利益相关者需求的文档形式。
话虽如此，以下是我在应用 Scrum 时看到的一些需求记录（为什么我觉得这个词后面应该总是跟一个星号？）：
而且，老实说，我不能说任何一个系统与成功项目的相关性始终高于其他系统。我想，确实，我们没有灵丹妙药。
HTH，感谢您提出发人深省的问题！
【讨论】：
在每个用户故事中添加“文档”作为一项任务当然可以大大有助于实现您的目标。
【讨论】：
Scrum 说你应该在需要的时候记录你需要的东西；它没有说你不应该有文件。
因此，如果成品（例如帮助文档）或生产成品（例如需求文档）需要文档，那么您的产品待办事项中应该有文档任务/用户故事。
然后应该为该任务设置适当的优先级。
对于文档来说，关键是；
【讨论】：
您不能只拥有用户故事 不知何故的功能 程序必须记录在案。你 最终得到一份规格文件 用scrum？如果你这样做了，你最终 分配时间来执行此操作 任务？
为什么不能只拥有用户故事？这些规范文件的目的是什么？制作这些文件的投资有什么回报？收益大于成本吗？如果没有，那么花费在创建，更重要的是维护这些文档上的时间不是浪费吗？
我知道我提出的问题比提供答案的要多，但我认为 Scrum 和其他敏捷方法（如精益）所做的部分工作是迫使您重新检查当前的实践，看看它们是否仍然有意义。
就规范而言，一旦功能启动，谁将更新和维护这些文档？在我工作过的大多数公司中，文档很少、过时或很少被引用。
相反，为什么不使用可执行测试或 BDD，以便文档成为代码的一部分并且是可执行的。例如，见Ben Mabey's talk on Cucumber
如果出于某种原因，出于法律合规目的需要特定类型的文档，您可以随时将其添加到团队对“完成”的定义中，但是，我发现在大多数情况下，故事和测试更多没有足够的文档形式。
【讨论】：
也许我对这个问题的理解完全错误，但我的理解是 OP 对用户故事和需求之间的不匹配感到不舒服。我会说是有道理的。
在我看来，用户故事讲述了如何向产品所有者展示一大块功能。故事的语言可以是产品所有者可以理解的东西，但主要是开发人员。您的故事可能会描述所有者甚至不直接要求的事物，而是对事物的细分。
另一方面，需求是用域用户的语言详细说明系统需要做什么才能有效。在许多情况下，需求文档不是可选的（例如固定价格项目）。
我所做的是两者兼而有之。我有一个需求文档，在我的大多数 Scrum 故事中，我的笔记中有一些东西将那个故事与一个或多个需求项联系起来。就像“参见 FR-042 和 FR-45”一样简单（例如功能要求的 FR）
【讨论】：
我认为您在这里要求一些不同的东西。如果您要添加新的团队成员，那么系统文档应针对他们在团队中的角色，作为入职流程的一部分。
如果您正在谈论记录系统功能；在我们的组织中，我们的培训团队将功能记录为发布的一部分。他们在 Sprint Review（演示）期间参与（作为利益相关者），然后提供了一个具有新功能的培训环境，以便在发布之前准备培训材料。
如果您正在谈论提供可追溯性的文档，您的待办事项可以作为添加适当流程和控制的待办事项。
这些不同的项目中的每一项都需要规划和深思熟虑的流程开发，以有效地发挥作用并满足团队的需求。我们已将这些项目中的每一项都包含在我们的回顾中，因为我们发现了一个问题，然后随着时间的推移制定了我们的流程。
【讨论】：
除了 James Kolpack 所说的，用户故事地图应该在项目完成后保留，因为它也是一种文档形式。我相信我们计划在完成所有工作后将其转换为存在于我们 Wiki 中的文档。
我们的想法是，该文档将对需要维护系统或在未来添加增强功能的人有用，因为他们将了解用户的观点。
【讨论】：
我基本同意 Todd，但有时我团队的部分任务是制作文档：文档本身就是用户故事我们的 PO 要求交付。
在这些情况下，我们遵循以下准则：
根据我的经验，这使文档更容易编写并启用某种测试（您要求某人，通常是 PO，阅读文档并说考虑到目标是否可以）。
【讨论】：
您编写文档来验证您的系统。如果以反映用户与系统交互的格式正确编写用户故事，则可以达到相同的目的。我会推荐使用 BDD 并使用 Gherkin 语法编写故事。最终，您的场景将成为您的验收标准，这有助于验证系统是否正常工作。
【讨论】：
我们有一个文档团队为我们的产品制作“说明手册”。该手册围绕产品的主要功能以及用户可以在这些功能中执行的任务进行构建。
每个 sprint，Scrum 团队都会处理为产品特性添加功能的用户故事。
在 sprint 计划之后，文档团队会与 Scrum 团队会面，看看将在这个 sprint 中开发哪些用户故事。然后，文档团队开始通过编写初始文档来增强说明手册。在 sprint 期间，文档团队跟踪用户故事的进度，并且可以在产品部署到测试环境时使用它。在冲刺结束时，文档团队完成更新的说明手册并添加最终屏幕截图等......
说明手册作为每个 sprint 版本的一部分提供。
【讨论】：