Jak radzisz sobie z prośbą o zmianę zakresu w trakcie Sprintu?

Question

Accepted Answer

Domyślnie w Scrum**e chodzi o ochronę Sprint Goal**: nie należy dodawać żadnych zmian, które mogą ją zagrażać. Ale Scrum nie jest sztywny — zakres można *wynegocjować ponownie z Product Ownerem*, a naprawdę pilna zmiana może być obsługiwana, gdy wyraźnie sformułuje się kompromisy.

## Ramework decyzyjny

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

## Konkretny przykład

W środku Sprintu dział sprzedaży chce "małego" nowego raportu. Scrum Master pomaga zespołowi i Product Ownerowi zrozumieć, że nie jest to pilne, więc trafia na górę backlogu następnego Sprintu zamiast zakłócać obecny cel.

## Częste błędy

- Cicho przejmowanie dodatkowej pracy, zmarnowanie Sprint Goal i ukrycie tego faktu.
- Powiedzenie płaskiego "nie" bez ścieżki — Product Owner zawsze może wynegocjować ponownie.
- Pozwolenie każdemu zainteresowanemu podmiotowi bezpośrednio wstrzykiwać pracę, omijając Product Ownera.

## Dlaczego to ważne

Ochrona Sprint Goal to to, co czyni Scrum przewidywalnym; ciągłe wstrzykiwanie zmienia Sprinty w chaotyczne listy zadań.

Obs ługa zmian poprzez Product Ownera z wyraźnymi kompromisami utrzymuje zespół skoncentrowany, jednocześnie pozostając responsywnym na rzeczywiste sytuacje kryzysowe.