Kuinka käsittelet pyyntöä muuttaa laajuutta Sprintin puolivälissä?

Question

Accepted Answer

Scrumissa oletusarvo on **suojata Sprint Goal**: mitään muutoksia, jotka vaarantavat sen, ei saa lisätä. Mutta Scrum ei ole jäykkä — laajuutta voidaan *neuvotella uudelleen Product Ownerin kanssa*, ja todella kiireellinen muutos voidaan käsitellä selkeillä kompromisseilla.

## Päätökseen tekemisen viitekehys

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

## Konkreettinen esimerkki

Sprintin puolivälissä myynti haluaa "pienen" uuden raportin. Scrum Master auttaa tiimiä ja Product Owneria näkemään, että se ei ole kiireellinen, joten se menee seuraavan Sprintin backlogin huipulle nykyisen tavoitteen häiritsemisen sijaan.

## Yleisiä ansoja

- Lisätöiden hiljainen imeminen, Sprint Goalin tuhoaminen ja sen piilottaminen.
- Jyrkän "ei" sanominen ilman reittiä — Product Owner voi aina neuvotella uudelleen.
- Kaikkien sidosryhmien antaminen injektoida työtä suoraan, Product Owneran ohittaminen.

## Miksi se on tärkeää

Sprint Goalin suojaaminen tekee Scrumista ennustettavaa; jatkuva injektio muuttaa Sprintit kaoottisiksi tehtävälistoiksi.

Muutoksen käsittely Product Ownerin kautta selkeiden kompromissien kanssa pitää tiimin keskittyneenä ja samalla reagoivana oikeille hätätilanteille.