一些团队使用sprint review （冲刺评审会）作为产品负责人或关键利益相关者，在正式批准sprint期间完成的产品待办事项列表。这是个好主意吗?
一般来说，一个sprint review（冲刺评审会）团队不应该使用Sprint review（冲刺评审会）来从他们的产品所有者那里获得正式的工作许可。团队和产品负责人应该在sprint中紧密合作，让团队知道产品负责人对他们所构建的产品有什么想法。
所以在sprint review（冲刺评审会）中，我的第一条规则是没有什么疑问的。
在产品待办列表中，产品负责人拒绝团队在产品待办事项列表中的工作是完全可以接受的。但是团队应该知道这是之后要解决的。
团队成员不应该在sprint review（冲刺评审会），期望得到产品负责人的赞同，因为随后会被一连串关于问题的抱怨所蒙骗。
但是客户的接受呢?在这些情况下，sprint review（冲刺评审会）可以用于正式的签署或接受吗?
理想情况下，在客户雇佣供应商开发产品的情况下，客户公司的一名人员将充当产品负责人。在这种情况下，可以在sprint review（冲刺评审会）期间对功能的提交建议进行正式暂时的关闭。但我仍然坚持在评审会期间不应该有额外的建议。
尽管客户产品所有者在Sprint中向团队提供反馈，但产品负责人可能需要等待，直到其他利益相关者有机会对工作进行评论时，才能完全接受某些东西。
举个简单的例子，我的女儿最近问我，她是否可以去学校旅行。这对我来说很好，但是——你猜怎么着——我们需要检查一下她母亲的情况。也就是说，我妻子可能在那段时间里对我们的家人有过计划，而我当时还不知道。
这将是客户产品所有者在合同开发情况下的常见情况。产品负责人每天与团队交流如何构建一个特性，但是可能需要确认他/她所代表的利益相关方是否同意。当然，我们可以说产品负责人应该简单地问一下。但这可能是不切实际的，最好是在sprint review（冲刺评审会）中完成。
但在外包、合同开发中，客户并不总是提供产品所有者。很多时候，客户会雇佣供应商来处理所有的事情。
当然，客户是真正的产品所有者。客户将最终接受或拒绝开发的东西。但是，在日常的基础上，客户不想被“打扰”，因此，在这种情况下，典型的解决方案是让供应商从自己组织内部的某个人中指定一个产品负责人。
在这种情况下，在sprint review（冲刺评审会）之前，不能在产品待办事项列表中实现真正的验收(或“关闭”)。真正的产品所有者(来自客户)没有足够的可用性，并且更频繁地接受事物。
当然，在sprint期间，团队可能会从他们自己的产品所有者代表中签署一份初步意向。但是，真正的客户端产品所有者可能会在实际的sprint review（冲刺评审会）中完全推翻这个决定。
所以最终的答案取决于很多事情，取决于你所处的环境。所以我要说的是，我不太建议在sprint review（冲刺评审会）过程中出现的正式的签字会。但我总想坚持一项不让人意外的对策。
根据需要签字或不签字。但是团队应该对即将到来的评论有一个很好的了解，在他们开始审查之前会发生什么。。
