我的公司实施了一个新流程，让团队负责sprint内部的Done定义。
在Sprint Review会议中，PO首次展示了工作，他们在团队面前完成每个问题，然后对问题发表评论，例如： “它是否按预期工作。如果没有，如何？缺陷产生......”
阅读很多关于Scrum的内容似乎不是“Scrum”就是做事情，实际上很多资源明确表示将审查会议作为接受会议是一件坏事，应该是关于反馈的
问题在于PO何时应该看到工作？我们什么时候接受/拒绝冲刺？
由于以下几个原因，我们目前没有在sprint中进行PO测试：
这些都是我们所做的所有假设，所以对这些的任何想法都会非常有用。
答案 0 :(得分：2)
Sprint Review是团队展示已经为更广泛的受众（通常是利益相关者）所做工作的机会。我们召开这次会议的原因是，并非所有对这项工作感兴趣的人都有时间在冲刺期间不断对其进行审查。他们在会议期间参加Sprint评审并提供反馈通常很方便。
我希望产品负责人在Sprint审核之前看到所有的功能。事实上，我与产品负责人合作的很多团队都是在Sprint评审中领导演示的人。实际上，他们正在向更广泛的受众展示他们要求发展的内容。
产品负责人在冲刺期间审核故事。我首选的方法是让开发人员尽早向产品负责人展示故事的功能，有时甚至在他们仍在开发时。产品负责人越早看到故事，他们就越早提供反馈。早期反馈对团队有效工作至关重要。
请注意，他们正在审核而非测试。虽然如果产品负责人团队合作并且产品负责人发现它有价值，那么产品负责人没有任何损害。
正如您正确指出的那样，产品负责人在冲刺期间有很多事情要做。由Scrum团队负责讨论产品负责人如何最好地花时间。就我个人而言，在冲刺期间审查故事是产品所有者的首要任务，因为它可以提高效率。