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.
不确定这是否像听起来那么简单。 我们也看到了细节部分的挑战。 假设我们正在开发一个需要捕获简单联系信息（例如 CRM 系统）的故事。 我现在有了来自 PO 的故事，我们参加了冲刺计划会议并了解了符合我们速度的前 5 个故事。 然而，捕获对话的所有细节总是很困难，例如屏幕需要如何布局、屏幕上需要有哪些 20 多个字段、其中一些字段是否可以从其他表/中查找信息意见等 谁捕获这些详细信息，应该是 PO 还是开发人员，以及存储这些详细信息的最佳实践是什么。 我们现在正在尝试使用 wiki 来实现此目的，但是，在尝试维护有关谁需要更新哪些详细信息以及何时更新的操作项时，这会成为一种开销。
Not sure if this is as simple as it sounds. We've seen challenges with the detail part as well. Lets say if we're developing on a story that requires capturing simple contact information for lets say a CRM system. I now have the stories from the PO and we went through the sprint planning meeting and understood the first 5 stories that meets our velocity. However its always a struggle on capturing all the details of the conversation, for example how the screen needs to be laid out, what are the 20+ fields you need to have on the screen, can some of these fields lookup information from other tables/views etc. Who captures those details, should it be the PO or developer and whats the best practice for storing these details. We're right now trying to use wiki's for this, however it becomes an overhead in trying to maintain the action items on who needs to update which details and by when.
My understanding is that specific requirements such as this are handled by the product owner. They will liase with the client during Sprint Planning 2 and update the tasks with specfic requirements as needed - hence why the Product Owner is a optional attendee of the Sprint Planning 2 meeting. This gives you a hybrid of Just-in-Time and Sprint Planning 2 population of the specifics. Anything that isn't satisfied by the time you come to work on the task will be an impediment and should be dealt with a the daily scrum, by the product owner.
As the development is Agile when using Scrum you shouldn't find too much of an issues getting requirements just in time.
发布评论
评论（4）
详细信息可以放在整个团队都可以使用并且可以由整个团队编辑的 wiki 中。
Detail can sit in a wiki available to the whole team and editable by the whole team.
Sprint 待办事项
Sprint backlog
不确定这是否像听起来那么简单。 我们也看到了细节部分的挑战。 假设我们正在开发一个需要捕获简单联系信息（例如 CRM 系统）的故事。 我现在有了来自 PO 的故事，我们参加了冲刺计划会议并了解了符合我们速度的前 5 个故事。 然而，捕获对话的所有细节总是很困难，例如屏幕需要如何布局、屏幕上需要有哪些 20 多个字段、其中一些字段是否可以从其他表/中查找信息意见等
谁捕获这些详细信息，应该是 PO 还是开发人员，以及存储这些详细信息的最佳实践是什么。 我们现在正在尝试使用 wiki 来实现此目的，但是，在尝试维护有关谁需要更新哪些详细信息以及何时更新的操作项时，这会成为一种开销。
Not sure if this is as simple as it sounds. We've seen challenges with the detail part as well. Lets say if we're developing on a story that requires capturing simple contact information for lets say a CRM system. I now have the stories from the PO and we went through the sprint planning meeting and understood the first 5 stories that meets our velocity. However its always a struggle on capturing all the details of the conversation, for example how the screen needs to be laid out, what are the 20+ fields you need to have on the screen, can some of these fields lookup information from other tables/views etc.
Who captures those details, should it be the PO or developer and whats the best practice for storing these details. We're right now trying to use wiki's for this, however it becomes an overhead in trying to maintain the action items on who needs to update which details and by when.
我的理解是，诸如此类的具体要求是由产品负责人处理的。 他们将在 Sprint Planning 2 期间与客户联络，并根据需要更新具有特定要求的任务 - 因此产品负责人是 Sprint Planning 2 会议的可选与会者。 这为您提供了 Just-in-Time 和 Sprint Planning 2 细节的混合体。 当你开始执行任务时，任何不满意的事情都将成为障碍，应该由产品负责人在每日例会中进行处理。
由于使用 Scrum 时的开发是敏捷的，因此您不应该发现太多及时获取需求的问题。
My understanding is that specific requirements such as this are handled by the product owner. They will liase with the client during Sprint Planning 2 and update the tasks with specfic requirements as needed - hence why the Product Owner is a optional attendee of the Sprint Planning 2 meeting. This gives you a hybrid of Just-in-Time and Sprint Planning 2 population of the specifics. Anything that isn't satisfied by the time you come to work on the task will be an impediment and should be dealt with a the daily scrum, by the product owner.
As the development is Agile when using Scrum you shouldn't find too much of an issues getting requirements just in time.