何时以及由谁承担这项工作以充分收集答案，以便我们可以开始为即将到来的 sprint 编写故事。这项工作是否与产品所有者的现有 sprint 连续并并行完成？我想这会为 sprint 创建任务，例如调查 x 和 y。如果 PO 突然要求开发人员通过尝试来回答一些问题怎么办？我理解尖峰和创建研发任务的想法。我想我想避免一个功能的主要开发过于频繁地延迟到下一个 sprint。
【问题讨论】：
标签： scrum estimation
团队决定在冲刺期间可以完成多少新故事工作。他们必须完成这项工作的时间占工作日的一定百分比。根据团队成员的职责（客户支持、错误修复、电子邮件、PTO、其他职责），该金额因团队而异。我希望看到 10-15% 的工作日专门用于“计划”下一个 sprint。这包括帮助 PO 研究、编写故事、分解故事、设计会议、假设场景等。我认为关键不是将这些类型的任务中的每一项都硬塞进冲刺中，而是设置正确的完成冲刺工作的时间分配。也许每周 30 小时是一个平均数字。
所以直接回答你的问题；计划工作与当前的 sprint 工作并行完成。
【讨论】：
我们通常会开一两次会议来讨论未来的故事。此外，我们在每个 sprint 中保留一些开销时间来检查我们需要知道的事情来开始一个故事。会议有助于确定哪些故事可能会在下一个 sprint 中出现，因此我们知道在当前 sprint 的保留时间内要回答哪些问题。
【讨论】：
对于我们来说，如果这是一个大型项目，我们将召开启动会议来集思广益。 PO 在他们想做什么和他们不知道我们可以做什么之间经常存在知识鸿沟，而这些会议可以填补这些空白。
创建新故事时，我们会尝试在下次计划会议之前的某个时间为他们分配故事点，以便 PO 有时间在该会议之前确定列表的优先级。
我不确定你所描述的那种情况，PO 会“突然”需要开发人员来尝试一些东西。在这种情况下，我会在下一个 sprint 中提供一个峰值。一般来说，使用新技术并不是每个 sprint 都会发生的事情，所以这应该足够了。如果不是这样，也许冲刺对于这个目的来说有点太长了（至少要考虑一个权衡）另一种选择是引入一个常青的故事来尝试一些东西。我见过团队有这类关于技术债务偿还的故事——你可以选择非此即彼的情况。有时开发者会修复技术债务，有时他们会尝试解决问题。而且，如果您以某种方式用完了技术债务，您总是可以抓住另一个常规故事来代替它。
【讨论】：
我们通常会在大版本发布后保留一两个冲刺，用于研究和概念验证故事。作为常规 sprint 的一部分进行研究似乎是有问题的。您可能会利用这段时间来吸收对增值故事的错误估计，最终永远不会将其用于实际研究。
如果一个新的故事落入需要研究的待办事项中，并且 PO 将其运行到您的待办事项的顶部，那么团队应该将一些研究时间纳入他们的实际估计中。如果我没有提前进行研究/原型设计冲刺，我只会这样做，因为估计研究可能有点模糊。
【讨论】：
谁：产品所有者。故事和产品积压是他的职责。产品负责人通常是有经验的人；即使他们不是技术人员，他们当然也可以在抽象级别上感知实现的复杂性。尽管如此，如果一个故事有灰色区域，PO 必须向正确的人提出正确的问题。他可以询问开发人员、测试人员、同行、客户甚至 scrum master。
何时：一直……连续。 PO 只能 (1) 为团队关于范围和功能的问题提供（或获取）答案，(2) 并收集数据以完善故事及其范围：从而主动解决团队的疑问。
底线是，如果产品负责人没有向团队讲述好故事，那么他就没有做好自己的工作。任何人都可以编写故事，但最终是 PO 确保产品待办列表井井有条，并定义了最优先的故事。
【讨论】：