在Sprint的中途，当要求改变范围时，您如何处理？

Question

Accepted Answer

Scrum的默认做法是**保护Sprint Goal**：不应该添加任何危害Sprint Goal的变更。但Scrum并非严格的——范围可以*与Product Owner重新协商*，真正紧急的变更可以被处理，但需要明确说明权衡。

## 决策框架

```text
1. Does the new request threaten the Sprint Goal?
     NO  → can it wait for the next Sprint? Usually yes → backlog it.
     YES → talk to the Product Owner about trade-offs.
2. Is it a genuine emergency (prod down, legal, security)?
     YES → the PO may cancel/replace work; something must drop.
3. Make the trade-off visible: pulling X in means Y comes out.
```

## 具体例子

Sprint进行到一半时，销售部门想要一份"小的"新报告。Scrum Master帮助团队和Product Owner了解这不是紧急事项，所以它被放在下一个Sprint待办事项的顶部，而不是打破当前的目标。

## 常见陷阱

- 默默地承担额外工作，破坏Sprint Goal并隐瞒它。
- 坚定地说"不"而没有任何解决路径——Product Owner总是可以重新协商。
- 让每个利益相关者直接注入工作，绕过Product Owner。

## 为什么这很重要

保护Sprint Goal是使Scrum具有可预测性的关键；不断的工作注入会将Sprint变成混乱的待办事项清单。

通过Product Owner处理变更并明确权衡，既保持团队专注，又能对真正的紧急情况做出响应。