Kako ravnaš s prošnjo za spremembo obsega sredi Sprinta?

Question

Accepted Answer

Privzeta nastavitev v Scrumu je **zaščita Sprintovega cilja**: ne bi smeli dodajati sprememb, ki bi ga ogrožale. Toda Scrum ni tog — obseg se *lahko ponovno pogaja s Product Ownerjem*, in resnično nujno spremembo je mogoče obravnavati z eksplicitno navedenih kompromisov.

## Okvir odločanja

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

## Konkretni primer

Sredi Sprinta prodaja želi »majhno« novo poročilo. Scrum Master pomaga ekipi in Product Ownerju, da vidita, da ni nujno, zato gre na vrh backlog-a naslednjega Sprinta, namesto da bi motila trenutni cilj.

## Pogosti pasti

- Tiho absorpcija dodatnega dela, porušenje Sprintovega cilja in skrivanje tega.
- Rečiti grobo »ne« brez poti — Product Owner se lahko vedno ponovno pogaja.
- Omogočanje vsakemu deležniku, da neposredno vbrizga delo, pri čemer obide Product Ownerja.

## Zakaj je to pomembno

Zaščita Sprintovega cilja je tisto, kar naredi Scrum napovedljiv; stalna vbrizgavanja spremenijo Sprinte v kaotične sezname opravil.

Obravnavanje sprememb prek Product Ownerja z eksplicitnimi kompromisi drži ekipo osredotočeno in hkrati odzivno na resnične nujnosti.