Sprint 规划目标

Sprint 规划将产品优先级转化为一个适用于短期固定周期的现实交付计划。会议结束时，团队应对 Sprint 目标达成共识，形成有价值工作的交付预测，并清楚了解风险和依赖关系。目标不是填满所有可用工时，也不是承诺完成待办列表中的每一项。目标是制定一份聚焦的计划，让利益相关者能够可靠地了解团队计划交付的内容。

有用的 Sprint 目标应描述团队试图实现的业务成果。例如，“改善首次客户引导体验”这样的目标，比“完成八个工单”更有用，因为当出现新信息时，它能帮助团队做出决策。如果某个低优先级工单不利于实现该目标，即使它在技术上已经就绪，团队也可以质疑是否应将其纳入 Sprint。产品负责人负责待办列表的排序，而开发人员负责确定合理可预测的工作量。

规划前，应确认 Sprint 时长、产品优先级、待办列表的状态，以及任何已经在进行中的工作。在 Jira 中检查待办列表，并确保候选事项具有易于理解的描述、验收标准、恰当的优先级，以及符合团队工作约定的估算。规划不应成为 refinement 的替代品。如果多个高优先级事项仍不明确，团队应记录这些不确定性，并避免将这些事项作为确定的交付承诺。

容量与工作选择

容量是指 Sprint 期间团队实际可用的工作时间。先从正常工作日开始计算，然后扣除节假日、计划休假、培训、支持值班、会议和其他职责。一支由六人组成的团队，实际可用于交付的时间可能远少于六个全职成员的工作量。专业技能方面的限制也会影响容量。例如，即使其他团队成员有空闲时间，测试瓶颈或安全审核人员的访问受限，也可能限制团队的吞吐量。

将近期交付数据用作合理性检查，而不是自动目标。如果团队通常完成 25 到 30 个 story point，但有两人休假，那么仅仅因为上个 Sprint 完成了 30 个 story point 就选择 30 个点，是一种薄弱的规划方式。交付预测应同时反映历史证据和当前状况。当产品服务于活跃客户或支持负荷较高时，团队还可以选择预留少量缓冲，以应对运营中断。

选择优先级最高、已经就绪且有助于实现 Sprint 目标的事项。在最终确定交付预测前检查依赖关系。依赖外部审批、数据迁移或其他团队的功能，虽然在技术上规模较小，但在运营上可能存在风险。在 Jira 中，将选定事项加入 Sprint，核实其排序，并确保事项关系和依赖说明对需要了解这些信息的人员可见。要区分交付预测和承诺：团队预测其认为能够完成的工作，而产品负责人和利益相关者应了解该预测背后的假设。

在 Jira 中执行 Sprint

在执行过程中，Jira 应让团队能够轻松了解当前情况，但不能取代团队沟通。使用 Scrum 看板展示已达成一致的工作流程，例如 To Do、In Progress、In Review 和 Done。具体列应与团队的交付流程保持一致。只有当相关工作确实达到下一状态时，工单才应移动。例如，如果仍需测试或验收，即使开发已经完成，也不应仅因开发结束就将 issue 移至 Done。

保持 issue 的负责人明确。每个处于活动状态的 issue 都应有明确负责的 assignee，或由团队明确约定责任归属。当某项决定、澄清或客户假设可能影响后续工作时，应添加有用的评论。避免把 Jira 变成每次对话的逐字记录。记录能够帮助其他团队成员了解当前状态、下一步行动或某项决定影响的信息。

有意识地管理进行中的工作。如果同时启动许多 issue，看板可能显得非常繁忙，但实际完成的工作却很少。团队应在拉取更多事项之前先完成高价值工作，同时遵循自身的工作流程和专业分工约束。如果某个 issue 被阻塞，应使用团队约定的 Jira 标记方式使阻塞状态可见，例如标记 issue、添加 blocker 标签、关联依赖项，或记录清晰的状态说明。具体采用哪种约定并不如持续一致地使用并快速跟进重要。

被阻塞的 issue 应包含阻塞原因、下一步行动的负责人以及预期复查时间点。例如，“等待支付服务提供商确认”比“Blocked”更具可执行性。如果阻塞因素威胁到 Sprint Goal，应在每日 Scrum 中提出，并升级给 Product Owner 或相关利益相关者。每日 Scrum 的目的是检查目标进展并调整计划，而不是让每个人逐一向经理汇报状态。

管理变更与风险

Sprint 并不是与业务现实隔离的。客户事件、监管要求、技术发现和依赖失败都可能需要团队响应。团队首先应评估该变更是否支持 Sprint Goal、是否能纳入剩余容量，以及哪些现有工作将因此被替代。在不移除其他工作或重新估算其他工作的情况下直接增加工作，会导致预测失去可靠性。

Product Owner 和 Developers 应明确说明取舍。如果紧急客户问题必须进入 Sprint，就移除一项价值较低的事项，或清楚说明预测已经发生变化。不要在 Jira 中悄悄保留原有范围，同时额外增加工作。更新 issue 优先级、Sprint 内容和相关评论，使看板反映当前计划。如果 Sprint Goal 已不再现实，应讨论能否通过调整范围来保留该目标，或者是否需要依据团队的 Scrum 实践对 Sprint 进行正式干预。

将风险作为触发决策的依据，而不是静态的登记表。风险应包含概率或影响评估、负责人以及计划采取的应对措施。例如，如果第三方集成方直到 Sprint 过半仍未确认其测试环境，团队可以切换到 mock 测试路径、升级处理该依赖，或将该集成事项从预测中移除。关键在于风险变成临近交付时的意外之前就作出决定。

利益相关者沟通与度量指标

利益相关者需要简明了解进展、信心程度、风险以及待决策事项。一次有用的更新应说明 Sprint Goal、已完成的工作、当前进行中的工作、存在风险的事项，以及预测是否发生变化。它应解释业务影响，而不只是报告工单在各列之间发生了移动。例如，说“客户账户恢复功能已准备好进行验收”比说“三个 issue 已进入 Done”更有价值。

根据项目配置，Jira 可以通过 Sprint 视图、看板、报告、仪表板和 issue 历史记录来支持这类沟通。谨慎使用燃尽图等报告。燃尽图可以显示剩余工作量是否随时间发生变化，但不能证明团队正在交付客户价值。曲线持平可能意味着存在阻塞、更新滞后、大型事项批量完成，或估算不准确。在对此作出反应之前，先弄清楚这一模式意味着什么。

跟踪一小组能够为决策提供支持的指标。实用的衡量指标包括：相对于预测的已完成工作、受阻问题的数量及持续时间、从开始到完成的周期时间、漏网缺陷，以及 Sprint Goal 的进展情况。避免使用 story points 来比较个人或团队。指标应揭示需要关注的状况，而不是促使团队夸大估算或追求工单数量。

审查与改进

在 sprint 结束时，与客户、用户或相关利益相关者一起检查 increment。展示已完成的成果，并记录会影响未来 backlog 排序的反馈。某个事项仅仅达到 Done 状态并不意味着它具有价值；团队应验证其是否满足约定的验收标准，以及成果在预期的业务场景中是否可用。

在 retrospective 中，同时评估计划和执行情况。将预测与实际完成情况进行比较，然后分析产生差异的原因。常见原因包括 refinement 不明确、隐藏的依赖工作、进行中的工作过多、后期变更，或产能假设与实际情况不符。在尚未理解导致该差异的系统性因素之前，避免将差异直接视为绩效评价。

为下一个 sprint 选择一到两项具体的改进措施。改进措施可以是：在规划前确认外部依赖、限制处于评审中的事项数量、为高风险 story 增加就绪检查，或为受阻工作定义更快速的升级路径。将行动记录在显眼的位置并指定负责人。只有当团队在后续 sprint 中改变某项行为、工作流程或决策规则时，retrospective 才具有实际价值。

核心原则很简单：围绕成果进行规划，根据实际产能验证预测，在 Jira 中清晰呈现工作和阻塞项，尽早沟通变更，并检查交付的 increment 是否创造了预期价值。这种方法既能让团队在执行过程中保持灵活性，又不会牺牲对客户和利益相关者的责任。