在sprint期间的PO细化问题

对你的PO感到满意。产品待办事项列表细化是一个连续的过程。如果它不是连续的，那么开发团队将会惊讶于每个sprint计划中不符合技术结构的新功能。

但是，当你将一组产品待办事项列表项目投入到冲刺阶段时，要知道你每天没有8个小时来处理它们。比如有人得了流感，顾客打电话寻求帮助，在自动售货机旁边喝杯咖啡。哦，还有通过产品负责人与涉众/客户/客户进行沟通。

和团队一起做什么级别的工作
>在冲刺时非正式的修饰会
>你认为可以接受吗?

尽管产品待办事项列表细化不是一个正式的Scrum事件，但它可以而且应该有时间限制。因此，在给定的Sprint中，团队可以选择为每个特定长度的特定数量的细化会话进行预算。该预算可以合理地包括花在任何刺突调查上的时间，以澄清可行性或范围。

细化活动不应该被允许超过预算的时间框，以免它们影响到计划的开发工作或以其他方式将Sprint目标置于危险之中。

谢谢大家，这很有帮助。

除了Ian的评论，Scrum指南在第13页提到了产品待办事项列表优化的最大预算为10%。

大卫,
你认为为什么PO会自发地这样做，而不是等待细化会话?
是因为他不知道由于任务转换而导致的生产力损失吗?如果是这样，你可以教他。也许他会学会更有效地利用团队的时间，而不是不必要地打断他们。
可能发生的情况是，采购订单向团队提出了问题，他需要立即得到答案，而在敏捷环境中，必须能够与团队交谈。然而，这应该是例外，而不是规则。

Ludwig在揭示任务切换的负担时提出了一个很好的观点;我只是让采购总监先和产品经理讨论一下，这样如果需要提出一些会改变当前sprint的问题，就可以尽快提出。尽快的定义通常是每个人都休息一下，吃点零食，或者在午餐前后，这样就没有切换任务的负担了。如果它可以推迟我们的时间盒细化
见面就更好了。让我们把它放在“改进会议期间要讨论的事情”清单上。

我建议在回顾期间创造一个空间来提出这个问题;使用一种允许更开放的交流的技巧，看看你得到了什么。采购主管很可能没有意识到他们对团队生产力的影响，而且很可能正在影响那里的关系。

当采购订单向团队提出问题时，可能需要有一个优先级级别的沟通。最终，采购订单需要与团队保持持续的沟通，以便有效地进行产品待办事项管理。这与团队与采购订单沟通他们可能有的任何问题是相互的。

确保开发团队将产品待办事项列表中的项目理解到所需的级别。

谁是产品负责人最重要的涉众?客户?还是首席产品负责人?还是其他身体?

谢谢，我希望这是真的!