在审阅会议中接受冲刺？以及其他一些评论问题

Question

我的公司已经实施了一个让团队负责冲刺内完成定义的新流程。

在Sprint评审会议上，采购订单首次显示工作，他们会在团队面前审阅每个问题，然后对问题发表评论，例如“它是否按预期工作，如果没有，如何创建缺陷......”

关于Scrum的阅读很多，这似乎不是“Scrum”是做事情，事实上很多资源明确地说将审核会议作为接受会议是一件坏事，它应该是关于反馈的。

问题在于PO何时应该看到这项工作？我们什么时候接受/拒绝冲刺？

我们目前没有在冲刺PO测试，因为有几个原因：

• 如果PO是冲刺然后确保问题的所有权被理解在测试期间不上团队，他们可以理解并实施一些东西，然后在他们向他们展示之后从PO中获得解释。
• 团队测试自己的工作也不那么需要，因为他们已经有PO来抓东西了。
• PO在冲刺时有很多事情要做，例如，积压梳理，会见客户，如果我们在冲刺期间加入测试，那么可能有太多事情要做。

再次，这些都是我们所做的所有假设，所以对这些的任何想法都会非常有帮助。

Answer 1

Sprint Review是一个团队向更广泛的受众（通常是利益相关者）展示工作的机会。我们参加这次会议的原因是，并非所有对这项工作感兴趣的人都有时间在冲刺期间不断对其进行审查。他们参加Sprint评审并在会议期间提供反馈通常很方便。

我期望产品负责人在Sprint Review之前看到全部的功能。实际上，我与产品负责人合作过的很多团队是在Sprint Review上领导演示的人员。实际上，他们正在展示他们向更广泛的受众发展的内容。

产品负责人审查冲刺期间的故事。我的首选方法是让开发人员尽早向产品负责人展示故事的功能，有时甚至在他们还在开发的时候。产品负责人越早看到故事的实际情况，越早提供反馈。早期反馈对于团队有效运作至关重要。

请注意，他们是审查不是测试。尽管产品负责人在团队和产品负责人发现它有价值时进行一些测试并没有什么坏处。

正如您正确指出的那样，产品负责人在冲刺期间需要做很多工作。由整个Scrum团队来讨论产品负责人如何花费最佳时间。就我个人而言，我认为在冲刺期间审阅故事是产品负责人的首要任务，因为它可以提高效率。