文档是用户故事吗？[关闭]

我们需要为过去几次冲刺中一直在开发的产品做一些用户文档。我们现在在下一个冲刺中开始一个新项目，采购订单正在将先前生产的产品的文档用作该冲刺的用户故事。

我只是想知道您对这种方法的看法。就个人而言，我不同意文档是Scrum中的用户故事，因为它不会产生任何代码。

编辑：谢谢您的意见。我的脑海里有一个冲刺是要实现一系列正在运行的软件，但是您的看法改变了我的看法。感谢您的所有答复。

在我看来，“作为X的用户，我需要知道X的工作原理”。这可能会导致书面文档或在线帮助。

关键不只是代码，它还满足用户的需求。

理想情况下，文档是每个用户故事的一部分，并且永远不会建立。但是，在现实世界中，这通常不会发生。在这种情况下，您应该创建一个用户案例，以赶上缺少的特定文档。

没错，它不会产生任何代码。但是它确实满足了用户需求，因此应该优先于其他用户需求。

如果这意味着它永远都做不到，因为正在处理该功能，那么您可能就不需要那么糟糕的文档了。

我同意Pdr的文件评估，如果它涉及需求，技术或项目文件。理想情况下，应将其纳入冲刺工作。

我觉得产品文档有很大不同，因为它是用户实际要求的交付品，并且直接为用户提供价值。当然应该理解，产品文档本质上不是技术任务，而是功能任务，并且可能适合或可能不适合项目中的技术资源。

我认为这应该是用户的故事，但是我认为应该将对业务需求，用户观点和良好的技术写作技能有深刻理解的项目资源分配给这些任务。理想情况下，如果有空缺，则应该是业务分析师，或者是对需求，用户故事和良好的技术写作技能有深刻了解的高级QA测试人员。这也可以是开发人员，但是由开发人员编写的产品文档往往质量不高或有用，因为开发人员通常与技术细节过于接近。

在我们组织中，负责维护和增强我们的持续集成系统的工具团队正在使用Scrum帮助他们管理工作。他们没有写代码，但是他们仍在练习Scrum。

为了具体回答您的问题，我想问一下团队是否认为该文档是“完成的定义”的一部分。

如果团队认为文档是“完成的定义”的一部分，那么就不需要额外的故事，并且除非编写并验证了文档，否则故事无法被接受。

如果团队认为文档不是“完成的定义”的一部分，那么我将创建一个单独的故事，以便产品负责人可以管理他们的工作。