在Scrum中，细节在哪里？

Question

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

在Scrum中，您显然有产品待办事项（“应用程序首先打开用户正在使用的最后一个文档。”）和sprint任务积压（“实现忘记密码屏幕”）。然而，在我看到的所有例子中，这两个项目在细节方面都相当高（设计适合便利贴）。

那么，细节在哪里？假设客户对库存管理屏幕有一些非常具体的要求，或者有一个复杂的API需要在后端集成，在哪里记录，如何以及谁捕获这些信息？它是否与积压分开，但是在准时制或其他方面填充？

Answer 1

Sprint backlog

  

sprint积压是一个很大的问题   详细文件包含   有关团队如何的信息   要实施要求   对于即将到来的冲刺。任务是   分解成几小时没有任务   超过16个小时。如果任务是   超过16小时，应该是   进一步细分。关于的任务   从未分配sprint backlog，   相反，任务是由注册的   团队成员随心所欲。

Answer 2

详细信息可以放在整个团队可用的维基中，并由整个团队编辑。

Answer 3

不确定这是否听起来那么简单。我们也看到了细节部分的挑战。让我们说如果我们正在开发一个故事，需要捕获简单的联系信息，比如说CRM系统。我现在有PO的故事，我们经历了sprint计划会议，并了解了满足我们速度的前5个故事。然而，它一直在努力捕获对话的所有细节，例如屏幕需要如何布局，你需要在屏幕上显示的20多个字段，这些字段中的一些可以从其他表中查找信息/观点等 如果是PO或开发人员，那么谁捕获这些细节，以及存储这些细节的最佳实践。我们现在正在尝试使用wiki，但是在尝试维护需要更新哪些细节以及何时更新的操作项时，它会成为一种开销。

Answer 4

我的理解是这样的具体要求由产品所有者处理。他们将在Sprint Planning 2期间与客户联系并根据需要更新具有特定要求的任务 - 因此，产品负责人为什么是Sprint Planning 2会议的可选参与者。这为您提供了Just-in-Time和Sprint Planning 2特定群体的混合体。当你开始完成任务时，任何不满意的事情都会成为障碍，并且应该由产品所有者处理每日争议。

由于在使用Scrum时开发是敏捷的，因此您不应该在及时获得太多问题。