产品负责人的Sprint计划提示

顾名思义，冲刺计划会议设置冲刺并确定可以做什么。 虽然这是一次重要的会议，但我发现有些产品所有者对此感到苦恼。 以下提示可帮助您思考如何使用会议并发现如何最大程度地利用会议。

准备好

确保在冲刺计划会议之前进行必要的准备工作。 是你想要什么明确的冲刺来实现，保证了产品积压适当精炼（或整理） ，并具有高优先级项目准备 。 出于以下两个原因，这是必需的：

首先，如果在没有适当准备产品积压的情况下开始进行冲刺计划，则您可能会在时间较短，时间较短的会议中进行积压和计划工作。 这使sprint计划工作变得充满挑战，并且可能使开发团队感到疲惫和压力，而不是被激励去启动新的sprint。

其次，一旦计划完成并且达成了冲刺目标，您就不能或至少不应更改冲刺的内容：保护冲刺不受更改，以使团队能够集中精力工作并做好工作。

请记住，产品积压整理应该是团队的工作，并且应该让开发团队成员参与积压工作。 有关何时进行产品积压整理的建议，请参阅我的文章“ 何时应进行产品积压整理？ ”。

专注于冲刺目标

尽管有许多计划技术可用来确定在一个sprint中可以完成多少工作-从使用网络时间到基于速度的计划，但您不必担心团队如何计划。 由团队选择合适的计划技术并确定合适的任务，取决于Scrum Master来支持团队成员并在必要时建议适当的技术。 作为产品所有者，您应该专注于建立一个共享的，有意义的sprint目标 ，该目标将指导团队的工作并解释为什么进行该工作。 如果您没有Scrum Master，则需要解决此问题：承担Scrum Master的职责很可能使您不堪重负，并且/或者导致您忽略了某些产品管理职责，正如我在“ 每个伟大的产品所有者都需要一个伟大的Scrum Master 。

冲刺目标可能解决特定的风险并帮助您获得相关知识，或者可能与完成或优化一项功能有关。 前者的一个示例是“查找用户是否愿意在初始注册过程中共享个人数据”以解决用户交互风险。 后者的示例可能是“完成仪表板，以便可以将其发布给测试用户”。 如果您通常使用鼓励发布的目标 ，那么每个冲刺目标都应该朝着下一个发布目标迈出一步。

虽然我的经验表明许多产品所有者不使用冲刺目标，但我发现它们非常有用。 它们提供目的和一致性； 它们促进利益相关者的沟通； 而且它们使分析和操作从向用户展示产品增量中获得的数据变得更加容易。 但是要充分利用冲刺目标，您必须确保它们对开发团队有意义，以便人们支持它们。

例如，如果您认为解决用户交互或与定价相关的风险应是冲刺的目标，但是开发团队坚持首先解决关键的技术风险，那么强制执行目标可能不是一个好主意。进入团队。 相反，要寻求每个人都同意的包容性和共同目标。 另外，也可以使用两个单独的目标，只要这是例外而不是正常情况：Scrum中默认使用一个共享的sprint目标，因为这会促进紧密的团队合作和协作。 另外，它倾向于使收集和分析相关用户反馈变得更加容易。

我希望在整理工作中确定一个候选的冲刺目标。 这避免了在没有明确为何要执行冲刺的情况下开始冲刺计划的风险。 一旦达成共享目标，开发团队将执行计划工作并验证目标是否现实。 如果不是这种情况，那么您将不得不调整目标并使其不太雄心勃勃，直到适合冲刺为止。 您可以下载我的sprint目标模板 ，该模板可帮助您制定清晰且可测试的sprint目标。

出席

作为产品所有者，您可能需要承担许多职责，以争取您的时间和精力； 参加另一个sprint计划会议可能不是您的重中之重。 尽管这是可以理解的，但我建议您努力在整个会议中出席。 如果可以，请与开发团队位于同一房间。 或者，通过视频会议参加。

这样做有两个原因：首先，冲刺计划会议是橡胶之路。 它确定了实际完成的工作，未来几天和几周内将执行的工作。 通过在场，您可以指导开发团队并回答问题。 这有助于开发团队出色地完成工作，并减少了您在冲刺期间回答问题的需要，从而节省了您的时间来处理其他职责，例如竞争对手分析和其他战略工作 。 多年来，我参加了许多冲刺计划会议，发现当开发团队成员分析产品待办事项并将其分解为任务时，经常会出现新的问题。

其次，如前所述，可能会发现初始冲刺目标不切实际，因此必须进行调整。 如果您不在场，那么您将无法影响并有助于重塑目标。 此外，您可能想了解为什么无法实现目标，因此您可以从中学习。

尊重团队说不的权利，但要让人们负责

软件开发是一个令人兴奋但要求很高的职业。 虽然我不想过分夸张，但我遇到了一些人，由于他们承受着很高的压力，他们遭受了心脏病发作和持久的食物不耐受。 因此，敏捷方法可以促进可持续发展的步伐 ：工作负荷和强度必须在很长一段时间内保持可持续发展，从而形成能够促进创造力和创新的健康工作环境。 Scrum通过授权开发团队成员确定冲刺的正确工作量来确保可持续的步伐。 因此，如果事实证明并非所有与sprint目标相关的高优先级项目都可以完成，则团队有权撤回并拒绝为sprint添加更多工作。

尽管您可能觉得必须完全达到冲刺目标（例如，您可能会面对利益相关者的挑战，或者您可能已经承诺了某些功能），但您应该避免试图迫使团队进行更多工作。 这将损害团队的所有权和责任感； 从本质上讲，团队将不再为达到冲刺目标负全部责任。 在最坏的情况下，人们会失去兴趣和动力，而不再关心产品。

同样，在sprint审查会议的sprint结束时，要求开发团队对达到商定的sprint目标负责。 如果团队有权决定他们可以承担多少工作，那么人们也有义务实现目标并完成工作。

但是不要误以为保证的承诺。 软件开发中可能发生无法预料的事情，包括生病或服务器故障。 此外，新组建的团队通常需要一些时间才能切实地计划并可靠地达到冲刺目标。 但是，如果您的团队在三到四次冲刺之后还没有学会做出现实的承诺，或者如果您的团队经常无法完成拉入冲刺的所有产品待办事项，那么请使用下一个冲刺回溯来调查并消除原因。C

翻译自: https://www.javacodegeeks.com/2018/09/sprint-planning-tips-product-owners.html