我们现在在几个项目中使用 Scrum 并取得了不同程度的成功，我现在有一个与文档相关的查询。
在 Scrum 中，您显然有产品待办事项（“应用程序从调出用户正在使用的最后一个文档开始。”）和 sprint 任务待办事项（“实施忘记密码屏幕”）。但是，在我看到的所有示例中，这两个项目在细节方面都相当高水平（被设计成贴合便利贴）。
那么，细节在哪里呢？假设客户对库存管理屏幕有一些非常具体的要求，或者有一个复杂的 API 需要在后端集成，这是在哪里记录的，如何以及谁捕获这些信息？它是否与积压工作分开，但以即时或其他方式填充？
sprint backlog 是一份非常详细的文档，其中包含有关团队将如何为即将到来的 sprint 实施需求的信息。任务被分解为小时，没有任务超过 16 小时。如果一项任务超过 16 小时，则应进一步细分。sprint backlog 上的任务永远不会被分配，而是由团队成员根据需要注册。
详细信息可以放在可供整个团队使用的 wiki 中，并且可以由整个团队进行编辑。
不确定这是否像听起来那么简单。我们也看到了细节部分的挑战。假设我们正在开发一个需要捕获简单联系信息的故事，例如 CRM 系统。我现在有来自 PO 的故事，我们通过了 sprint 计划会议并了解了符合我们速度的前 5 个故事。然而，捕捉对话的所有细节总是很困难，例如屏幕需要如何布局，屏幕上需要有哪些 20 多个字段，其中一些字段是否可以从其他表中查找信息/视图等。谁捕获这些细节，应该是 PO 还是开发人员，以及存储这些细节的最佳实践是什么。我们现在正在尝试使用 wiki 来解决这个问题，
我的理解是，诸如此类的特定要求由产品负责人处理。他们将在 Sprint 计划 2 期间与客户联络，并根据需要根据特定要求更新任务 - 因此产品负责人是 Sprint 计划 2 会议的可选参与者。这为您提供了 Just-in-Time 和 Sprint Planning 2 详细信息的混合体。任何在您开始执行任务时不满意的事情都会成为障碍，并且应该由产品负责人在每日例会中处理。
由于在使用 Scrum 时开发是敏捷的，因此您不应该发现太多及时获取需求的问题。