题目
如何处理Sprint评审会议中产品负责人的频繁需求变更？
信息
- 类型：问答
- 难度：⭐⭐
考点
Scrum角色职责,需求变更管理,沟通协调,Scrum事件的理解
快速回答
作为Scrum Master，处理需求变更的核心要点：
- 保护Sprint目标：明确当前Sprint内不接受变更
- 建立变更流程：引导PO将新需求加入产品待办列表
- 优化沟通机制：在Sprint计划会议前对齐需求
- 促进团队协作：组织PO与开发团队澄清需求优先级
- 持续改进：在回顾会议中分析变更根源
问题背景
在Sprint评审会议中，产品负责人(PO)频繁提出新需求或修改已完成工作，会破坏团队节奏，导致：
- 开发团队挫败感增加
- Sprint目标无法达成
- 技术债务累积
处理原则与步骤
1. 保护当前Sprint（核心原则）
原理说明：Scrum框架中，Sprint是固定时间盒，目标不应中途变更（Scrum指南原则）
最佳实践：
在评审会议中礼貌但坚定地说明："感谢这些重要反馈！根据Scrum规则，当前Sprint已结束，这些变更将纳入产品待办列表，在下个Sprint计划会议中评估优先级。"
2. 建立结构化变更流程
操作步骤：
- 立即记录新需求到产品待办列表（PBL）
- 引导PO填写需求价值描述：
| 需求ID | 业务价值 | 预期指标提升 | 关联目标 |
|--------|----------|--------------|----------|
| PO-102 | 提升转化率 | +15%注册率 | Q3营收目标 | - 要求PO提供验收标准（INVEST原则）
3. 优化需求对齐机制
常见错误：
- 允许PO直接向开发人员提需求（破坏Scrum流程）
- Sprint目标不清晰导致频繁变更
改进方案：
| 会议 | 改进措施 |
|---|---|
| Sprint计划会议 | 要求PO准备就绪定义(DoR)明确的需求 |
| 每日站会 | Scrum Master拦截PO的临时需求插入 |
| 产品待办列表梳理 | 预留20%容量处理紧急变更 |
4. 根本原因分析与持续改进
在回顾会议中：
- 使用5 Why分析法挖掘变更根源：
问题：PO频繁变更需求
→ Why1：市场变化快？
→ Why2：需求描述不清晰？
→ Why3：缺乏用户调研？ - 实施改进措施：
- 建立需求影响矩阵评估变更成本
- 引入功能开关(feature toggles)降低变更风险
扩展知识
- 紧急变更处理：若必须中断Sprint，需全体成员同意并重置Sprint目标
- 度量指标：跟踪需求稳定性指数（RSI=1-变更需求数/总需求数）
- 工具支持：在Jira中配置变更工作流，强制要求填写价值说明
典型对话示例
PO："这个按钮颜色需要立刻改成蓝色！"
Scrum Master："理解这个调整很重要，我们这样做：
1. 记录到PBL并评估影响范围
2. 明天待办列表梳理会优先讨论
3. 如果紧急，可替换等量未开始任务"
团队："更改需要重做UI测试，建议下个Sprint实施"
