Как вы справляетесь с запросом на изменение scope в середине Sprint?

Question

Accepted Answer

Стандарт в Scrum — **защитить Sprint Goal**: нельзя добавлять изменения, которые ставят его под угрозу. Но Scrum не жесткий — scope можно *переговорить с 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'у увидеть, что это не срочно, поэтому он переходит в начало backlog'а следующего Sprint'а вместо того, чтобы нарушить текущую цель.

## Частые ошибки

- Молча принимать дополнительную работу, нарушить Sprint Goal и скрыть это.
- Сказать категорический «нет» без пути решения — Product Owner всегда может переговорить.
- Позволить каждому заинтересованному лицу напрямую добавлять работу, обходя Product Owner'а.

## Почему это важно

Защита Sprint Goal — это то, что делает Scrum предсказуемым; постоянные изменения превращают Sprint'ы в хаотичные списки дел.

Обработка изменений через Product Owner'а с явными компромиссами держит команду сосредоточенной, оставаясь готовой к реальным чрезвычайным ситуациям.