Jak se vypořádáte s požadavkem na změnu rozsahu uprostřed Sprintu?

Question

Accepted Answer

Výchozí stav ve Scrumu je **chránit Sprint Goal**: neměly by být přidávány žádné změny, které by ho ohrožovaly. Scrum však není rigidní — rozsah lze *renegociovat s Product Ownerem*, a skutečně urgentní změnu lze zvládnout s explicitně definovanými kompromisy.

## Rozhodovací rámec

```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.
```

## Konkrétní příklad

Uprostřed Sprintu chce prodej "malou" novou zprávu. Scrum Master pomáhá týmu a Product Ownerovi vidět, že není urgentní, takže jde na vrchol backlogu příštího Sprintu místo aby narušila aktuální cíl.

## Běžné chyby

- Tiché přehlcování dodatečnou prací, ničení Sprint Goal a skrývání toho.
- Řeč prostého "ne" bez řešení — Product Owner může vždy renegociovat.
- Povolení každému stakeholderovi přímého vkládání práce, obcházení Product Ownera.

## Proč to záleží

Ochrana Sprint Goal je to, co dělá Scrum předvídatelným; neustálé vkládání mění Sprinty v chaotické seznamy úkolů.

Zpracování změn prostřednictvím Product Ownera s explicitními kompromisy udržuje tým soustředěný při zachování schopnosti reagovat na skutečné urgentní situace.