Sprint 评审是什么
Sprint 评审在每个迭代结束时进行，团队向干系人演示可运行的增量、收集反馈，并据此更新产品待办列表。它是一场工作会话而不是单向汇报：干系人对交付价值作出判断，产品负责人据此调整优先级，需要时重新讨论后续方向。一个月迭代的评审通常不超过四小时，两周迭代一般控制在一到两小时。
基本信息
| 参与者 | 产品负责人、开发团队、Scrum Master、真实用户或业务代表、受邀干系人 |
|---|---|
| 输入 | 本轮完成的可运行增量、Sprint 目标、完成定义与验收准则 |
| 时间盒 | 一个月迭代不超过 4 小时，两周迭代通常 1-2 小时 |
| 标准输出 | 反馈清单、更新后的产品待办列表、后续方向调整结论 |
| 成功判据 | 干系人基于实际演示给出反馈，且反馈被转化为待办条目 |
典型使用场景
- 迭代收尾验证：让业务方确认增量是否可用于试点或上线
- 方向校准：产品负责人根据反馈调整优先级与路线图
- 需求澄清：演示中暴露的模糊需求当场澄清，减少后续返工
- 跨团队集成确认：邀请上下游团队确认接口行为与数据一致性
- 上线准备沟通：对即将发布的增量确认部署窗口与回滚方案
评审会要点（文字示意）
评审会要点（文字示意）
展示：现场操作可运行的系统，不用幻灯片代替演示 # 演示即验收的依据
路径：按真实用户场景走一遍主流程，包含异常分支 # 只演示顺利路径会漏掉真实问题
未完成项：明确说明哪条没达到完成定义及原因 # 未完成必须显式披露
反馈：记录干系人对价值的判断与调整建议 # 反馈要落到待办条目
更新：现场或会后更新产品待办列表并标注优先级与责任人 # 不更新则评审失去调整作用
时间盒：控制演示与讨论节奏，超时议题另约时间反馈归类与处理
| 反馈类型 | 判断要点 | 处理方式 |
|---|---|---|
| 新需求 | 是否服务当前产品目标、价值量级如何 | 进入产品待办列表，由产品负责人重排优先级 |
| 缺陷 | 影响范围与严重度、是否影响既有用户 | 按严重度入待办列表，影响上线的立即修复 |
| 方向质疑 | 是否涉及产品定位或目标调整 | 更新目标与路线图讨论，必要时召集专门决策会 |
| 使用体验类建议 | 是否属于本迭代增量范围 | 记录为改进条目，合并到后续迭代 |
评审要邀请真实用户或业务代表：只对内部团队演示，容易漏掉真实使用场景与流程断点。演示环境与数据尽量接近生产，避免在评审现场花大量时间解释环境差异。