现在，我们已经在一些项目上使用Scrum并取得了不同的成功，现在我有一个与文档有关的查询。

在Scrum中，我们显然有产品积压("应用程序首先显示用户正在使用的最后一个文档。")和sprint任务积压("实现忘记密码的屏幕")。但是，在我所看到的所有示例中，这两项在细节方面都相当高(根据便利贴设计)。

那么，细节在哪里呢？假设客户对库存管理屏幕有一些非常特定的要求，或者有一个需要与后端集成的复杂API，该文档记录在哪里，如何以及由谁捕获此信息？它是否与待办事项分开，但是按时或者以其他方式填充的？

解决方案

我的理解是，诸如此类的特定要求由产品所有者负责。他们将在Sprint Planning 2期间与客户联络，并根据需要更新具有特定要求的任务，因此，为什么产品负责人是Sprint Planning 2会议的可选参加者。这为我们提供了即时和Sprint Planning 2细节的混合体。在我们完成这项任务时，任何不满意的事情都会成为障碍，并且应该由产品所有者每天处理。

由于使用Scrum时开发是敏捷的，因此我们不会在及时获取需求方面发现太多问题。

冲刺积压

The sprint backlog is a greatly
  detailed document containing
  information about how the team is
  going to implement the requirements
  for the upcoming sprint. Tasks are
  broken down into hours with no task
  being more than 16 hours. If a task is
  greater than 16 hours, it should be
  broken down further. Tasks on the
  sprint backlog are never assigned,
  rather tasks are signed-up for by the
  team members as they like.

细节可以放在整个团队都可以使用的Wiki中，并且整个团队都可以编辑。

不知道这是否听起来那么简单。我们在细节部分也看到了挑战。假设我们要开发的故事需要捕获简单的联系信息，例如CRM系统。现在我有了来自PO的故事，我们经历了冲刺计划会议，并了解了符合我们速度要求的前5个故事。但是，在捕获对话的所有细节(例如如何布置屏幕，屏幕上需要具有20多个字段)时总是很费劲，其中一些字段可以从其他表格/中查找信息意见等
谁来捕获这些详细信息，应该是采购员还是开发人员？存储这些详细信息的最佳实践是什么？我们现在正在尝试为此使用Wiki，但是，在试图维护有关谁需要更新哪些详细信息以及何时更新这些操作的操作项时，这是一项开销。