我是 Scrum 新手，虽然我了解 Sprint 背后的团队概念，但我想仍然需要一个团队的监护人，以尽量减少不熟悉软件开发的产品负责人的干扰。你的成功是什么，你经历过哪些恐怖故事？
更新：
我正在寻找实现业务流程的编码与为客户创建适当的架构之间的平衡。如果产品负责人来自业务部门，则必须指导应该在数据模型上花费多少时间等。
定义：
我所说的“失控”产品负责人通常是指业务部门中的某个人，他们积极设定时间框架，但没有真正的技术能力来创建该估计。通常这个人会说：“在下周与运营委员会的下一次会议之前，我需要这些屏幕，所以首先优先考虑这些工作产品。我们将在与运营部交谈后处理数据库。”
每个人都很好的答案。谢谢你的好意见。
Scrum 中明确定义了职责——产品负责人定义待办事项并确定它们的优先级，开发人员承诺他们在 Sprint 中可以做多少。
因此，产品负责人根本无权设定估算值。当然，他仍然可以说他在特定的时间点需要一些东西——这很容易发生。但是能不能做到，还是要开发商说了算。如果不能，他们必须共同研究如何更改范围或采取其他措施以尽可能最好地满足 PO 的需求。
现在，在这种情况下，SM 应该如何行动，这在很大程度上取决于具体情况。不过，我宁愿看到他促进 PO 和团队之间的良好关系和沟通文化，也不愿让他保护团队免受 PO 的影响。
“必须有关于应该在数据模型上花费多少时间等的指导。”
对。这就是优先级的全部意义所在。你定义工作，你优先考虑。你按照优先级工作。
什么会失控？
在完成任何工作之前重新定义工作？
在工作完成之前重新定义优先级？
解决方法是一样的。将工作分解成更小的部分，以便在有机会做出改变之前完成一些事情。
如果您的冲刺时间很短（2 周），就不可能失控。如果您进行稍微实用的 4 周冲刺，那么您遇到麻烦的可能性很小。
产品负责人应该是保护您免受模棱两可或多变的客户要求的人。
产品所有者不得给出估算值。
我不认为这是一个“失控”的问题。
“在下周与运营委员会的下一次会议之前，我需要这些屏幕，所以首先优先考虑这些工作产品。我们将在与运营部门交谈后处理数据库。”
这句话本身并没有什么本质上的错误。如果您的应用程序被正确抽象，那么您的数据库无论如何都是独立的。UI 的主要问题首先是更多的心理问题：非开发人员会认为如果他们看到屏幕并在事情“慢下来”时发疯，他们就会认为大部分工作已经完成。但是，我认为您的真正问题可能是：
您标记为产品负责人的人没有拥有产品，因此没有承担足够的责任。
产品是整个事物，而不仅仅是“功能需求”（借用术语）。您的 SM 需要坐下来，并坚持 PO 不需要试图推迟了解需要完成的幕后工作的范围。一旦您的 PO 开始着眼于整个范围，那么他们实际上可以成为您在更广泛的利益相关者社区中的代表。
最终，您的 SM 负责执行流程。他们应该这样做。
我在两家不同的商店使用过敏捷，两次都运行良好。我看不出任何失控的东西会如何破坏系统。在 sprint 之前，你计划好你将要做的所有任务，并猜测它们需要多长时间（总是四舍五入）。然后，您可以大致计算出在您的 sprint 期间可以完成多少工作。
大多数商店使用 4 周的冲刺，每天 6.5 小时的工作时间。设置 sprint 后，您不会引入新任务，只有潜入 sprint 的计划外工作会修复您正在添加的功能中的错误，当然这应该包含在您的估计时间中。
如果您想要更具体的答案，您需要定义“失控”产品所有者的意思。
我有两件事要说。
你可能有某种类型的研发经理（不一定是 Scrum Master），也不是产品负责人）。
这个人可以而且应该（我认为）“保护”开发人员。当我们有这样一个人时，我们就处于这种情况，而且效果很好。例如，他帮助我们在积压工作中获得了非功能性的东西。
现在我们没有这个人了。我们的经理是 Scrum Master。他在保护我们方面也做得很好。虽然......这里的问题是通用 scrum master 没有官方权力，所以他不能说“你不会这么压他们”，但如果他看到团队需要帮助，他当然可以而且应该说。
团队本身和产品负责人也随着时间的推移而发展，因此他们开始更加关心彼此。产品负责人理解团队何时不承诺更多或说“我们现在需要一些时间来处理非功能性的东西”。
但话又说回来 - 如果有一个单独的研发经理，其主要职责是照顾开发人员，那当然很好......那么我认为它会更加平衡......
我们还有支持部门借用开发人员来完成支持任务。有时很难就该客户或该客户将要做什么或不做什么达成一致（因为支持需要这一切）。对于这种情况，研发经理 - 也是一个非常好的主意..
理想情况下，我喜欢这个想法完全精简，这样开发人员就不需要经理或盾牌……但我不知道它是否以及如何运作……:)
我同意 S. Lott 的观点。短冲刺更好。简短的用户故事可以提供帮助。我们尝试将我们的用户故事限制在最多 2 到 4 天。
确保您的所有用户故事都定义明确并且所有者同意他们。
sprint 开始后，坚持不能将新任务添加到当前 sprint 中，但它们可以在下一个 sprint 中具有高优先级。更短的冲刺使这更容易。
此外，为了消除人为的最后期限的强加，您真的不应该在可能的情况下从当前的 sprint 直到下一个 sprint 的开始交付项目。
敏捷开发最难的部分是纪律。一旦你有一个纪律严明的团队和 scrum master，用户就会习惯它，事情就会变得更加顺利。我不确定您是否使用任何软件进行项目管理，但看看 Rally。在过去一年左右的时间里，他们取得了一些重大改进。
在迭代期间不应更改迭代（Scrum 中的 Sprint）范围。这就是为什么一次只计划一个迭代。正如 S. Lott 指出的那样，迭代越短，产品负责人就能越早计划新事物。
Scrum Master 的角色是将团队与这种压力隔离开来，并告诉产品负责人新的请求必须等待下一次迭代。
现在 Product Owner 的角色是最大化团队生产的工作的价值，所以如果有一个新的最高优先级项目，它不能等待当前迭代结束，仍然可以替换具有相似估计的项目而且还没有开始。这应该是例外，而不是规则。
坚持明确定义的参与规则，那么您（SM）可以花时间领导您的团队。
敏捷团队由开发人员、业务分析师、测试人员、DBA、Scrum master 和产品负责人组成。所有人都作为一个基于功能的团队工作。
敏捷方法可以帮助企业加快产品开发速度。产品所有者可以定义优先级并更改其优先级。实际上，它是一个 Scrum 团队，他们估计它包括（SME、开发人员、设计师、测试人员……每个人）。每个团队成员对产品和交付用户故事所需的工作都有不同的看法，一个 sprint 包括大和小的用户故事。如果 Scrum 团队觉得它不能在 sprint 中完成，那么它需要分成用户故事的一小部分，并根据开发它所涉及的堆栈跟踪进行估计。
即如果产品负责人（PO）希望特定的用户故事需要首先完成，但如果该故事包含多个更改（即前端和后端，包括数据库）并且无法在一个 sprint 中完成，Scrum 团队可以遵循以下关键规则：
关键要素：
如果 Still PO 有优先级的问题，他/她可以咨询 Scrum Master/Coach。
乍一看，敏捷更多的是帮助业务，但需要注意它不会使 Scrum 团队超载。因为它是迭代开发的常规过程。