团队决定在冲刺期间可以完成多少新故事工作。他们完成这项工作的时间占工作日的一定比例。根据团队成员的职责（客户支持、错误修复、电子邮件、PTO、其他职责），该金额因团队而异。我喜欢看到 10-15% 的工作日专门用于“规划”下一个冲刺。这包括帮助 PO 研究、撰写故事、分解故事、设计会议、假设场景等。我认为关键不是将每一项此类任务硬塞到冲刺中，而是设定正确的目标进行冲刺工作的时间分配。也许每周 30 小时是一个平均数字。
所以直接回答你的问题；规划工作与当前的冲刺工作并行进行。
The team determines how much new story work it can do during a sprint. The amount of time they have to do that work is some percentage of the work day. Depending on the responsibilities of team members (customer support, bug fixes, emails, PTO, other duties) that amount varies from team to team. I like to see 10-15% of the work day dedicated to "planning" for the next sprint. That includes helping the PO research, writing stories, breaking up stories, design sessions, what-if scenarios, etc. I think the key is not to shoe-horn every one of these types of tasks into a sprint but rather to set the correct time allocation to doing the sprint work. Maybe something like 30 hours/wk is an average number.
So to directly answer your question; the planning work is done in parallel to the current sprint work.
We usually have one or two meetings to talk about future stories. Also, we reserve some overhead time in each sprint to check out things we need to know to start a story. The meetings help determining which stories will probably shop up in the next sprint, so we know which questions to get answers to during the reserved time in the current sprint.
For us, if it's a large project, we will have kickoff meetings to brainstorm the project. There is often a knowledge gap for PO's between what they want to do and what they don't know we can do that these meetings can fill.
When new stories are created, we try to assign story points to them at some point before the next planning meeting so the PO has time to prioritize the list before that meeting.
I'm not sure of the kind of situation you describe where a PO would "suddenly" need a dev to try stuff out. In that case, I would offer a spike in the next sprint. Generally using new technologies isn't something that happens every sprint so this should suffice. If not, perhaps the sprints are a bit too long for this purpose (a trade off to be considered at least) Another alternative would be to introduce an evergreen story for trying stuff out. I've seen teams have these kinds of stories for tech debt payback - you could off an either/or situation. Sometimes dev fixes tech debt, sometimes they try stuff out. And if you run out of tech debt somehow, you can always grab another regular story to put in its place.
We typically reserve a sprint or two after a big release for research and proof of concept stories. Doing research as part of the regular sprint seems like it would be problematic. You'd probably use that time to absorb mis-estimations for value-adding stories and end up never using it for actual research.
If a new story drops into the backlog that needs research and the PO runs it up to the top of your backlog then the team should include some research time into their actual estimate. I would only do that if I didn't have the luxury of a research/prototyping sprint ahead of time though since estimating research can be a bit nebulous.
何时：一直..连续。 PO 不得做任何事情，除了 (1) 为团队关于范围和功能的问题提供（或获取）答案，(2) 并收集可完善故事及其范围的数据：从而主动解决团队的疑问。
最重要的是，如果产品负责人没有向团队提供好的故事，那么他就没有做好自己的工作。任何人都可以编写故事，但最终由 PO 来确保产品待办事项列表井然有序，并定义最优先的故事。
Who: Product owner. Stories and Product backlog are his responsibilities. Product owners are generally experienced people; even if they are not technical they can certainly perceive implementation complexities at abstract level. Still, if a story has gray area PO must ask right people the right question. He can ask developers, testers, peers, clients and even scrum masters.
When: all the time.. Continuously. PO must not do anything but (1) provide (or get) answers for the team’s questions regarding scope and function, (2) and gather data that would refine the stories and their scope: thus proactively solving the queries of his team.
Bottom line is if product owner is not giving good stories to the team then he is not doing his job. Stories can be written by anyone but in the end it’s PO who ensure that Product Backlog is in order and that top priority stories are defined.
发布评论
评论（5）
团队决定在冲刺期间可以完成多少新故事工作。他们完成这项工作的时间占工作日的一定比例。根据团队成员的职责（客户支持、错误修复、电子邮件、PTO、其他职责），该金额因团队而异。我喜欢看到 10-15% 的工作日专门用于“规划”下一个冲刺。这包括帮助 PO 研究、撰写故事、分解故事、设计会议、假设场景等。我认为关键不是将每一项此类任务硬塞到冲刺中，而是设定正确的目标进行冲刺工作的时间分配。也许每周 30 小时是一个平均数字。
所以直接回答你的问题；规划工作与当前的冲刺工作并行进行。
The team determines how much new story work it can do during a sprint. The amount of time they have to do that work is some percentage of the work day. Depending on the responsibilities of team members (customer support, bug fixes, emails, PTO, other duties) that amount varies from team to team. I like to see 10-15% of the work day dedicated to "planning" for the next sprint. That includes helping the PO research, writing stories, breaking up stories, design sessions, what-if scenarios, etc. I think the key is not to shoe-horn every one of these types of tasks into a sprint but rather to set the correct time allocation to doing the sprint work. Maybe something like 30 hours/wk is an average number.
So to directly answer your question; the planning work is done in parallel to the current sprint work.
我们通常会举行一两次会议来讨论未来的故事。此外，我们在每个冲刺中保留一些管理时间来检查开始故事所需了解的内容。这些会议有助于确定哪些故事可能会在下一个冲刺中购买，因此我们知道在当前冲刺的预留时间内需要回答哪些问题。
We usually have one or two meetings to talk about future stories. Also, we reserve some overhead time in each sprint to check out things we need to know to start a story. The meetings help determining which stories will probably shop up in the next sprint, so we know which questions to get answers to during the reserved time in the current sprint.
对我们来说，如果这是一个大型项目，我们将召开启动会议来集思广益。对于 PO 来说，他们想要做的事情和他们不知道我们可以做的事情之间经常存在知识差距，而这些会议可以填补这些知识差距。
创建新故事时，我们会尝试在下一次计划会议之前的某个时间点为它们分配故事点，以便产品负责人有时间在会议之前确定列表的优先级。
我不确定您所描述的那种情况是 PO“突然”需要开发人员来尝试一些东西。在这种情况下，我会在下一个冲刺中提供一个峰值。一般来说，使用新技术并不是每次冲刺都会发生，所以这应该足够了。如果不是，也许冲刺对于这个目的来说有点太长了（至少要考虑权衡）另一种选择是引入一个常青的故事来尝试东西。我见过团队有这样的技术债务偿还故事 - 你可以摆脱非此即彼的情况。有时开发人员会修复技术债务，有时他们会尝试一些东西。如果你以某种方式耗尽了技术债务，你总是可以抓住另一个常规故事来代替它。
For us, if it's a large project, we will have kickoff meetings to brainstorm the project. There is often a knowledge gap for PO's between what they want to do and what they don't know we can do that these meetings can fill.
When new stories are created, we try to assign story points to them at some point before the next planning meeting so the PO has time to prioritize the list before that meeting.
I'm not sure of the kind of situation you describe where a PO would "suddenly" need a dev to try stuff out. In that case, I would offer a spike in the next sprint. Generally using new technologies isn't something that happens every sprint so this should suffice. If not, perhaps the sprints are a bit too long for this purpose (a trade off to be considered at least) Another alternative would be to introduce an evergreen story for trying stuff out. I've seen teams have these kinds of stories for tech debt payback - you could off an either/or situation. Sometimes dev fixes tech debt, sometimes they try stuff out. And if you run out of tech debt somehow, you can always grab another regular story to put in its place.
我们通常会在大版本发布后保留一两个冲刺，用于研究和概念验证故事。将研究作为常规冲刺的一部分似乎是有问题的。您可能会利用这段时间吸收对增值故事的错误估计，最终永远不会将其用于实际研究。
如果一个新的故事落入需要研究的待办事项列表中，并且采购订单将其运行到待办事项列表的顶部，那么团队应该在他们的实际估计中包含一些研究时间。只有在我没有提前进行研究/原型设计冲刺的情况下，我才会这样做，因为估计研究可能有点模糊。
We typically reserve a sprint or two after a big release for research and proof of concept stories. Doing research as part of the regular sprint seems like it would be problematic. You'd probably use that time to absorb mis-estimations for value-adding stories and end up never using it for actual research.
If a new story drops into the backlog that needs research and the PO runs it up to the top of your backlog then the team should include some research time into their actual estimate. I would only do that if I didn't have the luxury of a research/prototyping sprint ahead of time though since estimating research can be a bit nebulous.
谁：产品负责人。故事和产品积压是他的职责。产品负责人一般都是有经验的人；即使他们不是技术人员，他们也肯定可以在抽象层面上感知实现的复杂性。尽管如此，如果一个故事有灰色地带，PO 必须向正确的人提出正确的问题。他可以询问开发人员、测试人员、同行、客户甚至 Scrum Master。
何时：一直..连续。 PO 不得做任何事情，除了 (1) 为团队关于范围和功能的问题提供（或获取）答案，(2) 并收集可完善故事及其范围的数据：从而主动解决团队的疑问。
最重要的是，如果产品负责人没有向团队提供好的故事，那么他就没有做好自己的工作。任何人都可以编写故事，但最终由 PO 来确保产品待办事项列表井然有序，并定义最优先的故事。
Who: Product owner. Stories and Product backlog are his responsibilities. Product owners are generally experienced people; even if they are not technical they can certainly perceive implementation complexities at abstract level. Still, if a story has gray area PO must ask right people the right question. He can ask developers, testers, peers, clients and even scrum masters.
When: all the time.. Continuously. PO must not do anything but (1) provide (or get) answers for the team’s questions regarding scope and function, (2) and gather data that would refine the stories and their scope: thus proactively solving the queries of his team.
Bottom line is if product owner is not giving good stories to the team then he is not doing his job. Stories can be written by anyone but in the end it’s PO who ensure that Product Backlog is in order and that top priority stories are defined.