Hvordan håndterer du en forespørsel om å endre omfang midt i en Sprint?

Question

Accepted Answer

Standarden i Scrum er å **beskytte Sprint-målet**: ingen endringer bør legges til som setter det i fare. Men Scrum er ikke rigid — omfanget kan *forhandles på nytt med produkteieren*, og en virkelig presserende endring kan håndteres, med klare avveininger.

## En beslutningsramme

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

## Konkret eksempel

Midt i Sprint ønsker salg en "liten" ny rapport. Scrum Master hjelper teamet og produkteieren med å se at det ikke er presserende, så det går til toppen av neste Sprints backlog i stedet for å forstyrre det nåværende målet.

## Vanlige feller

- Stille ta på seg ekstra arbeid, sprenge Sprint-målet og skjule det.
- Si et flatt "nei" uten noen løsning — produkteieren kan alltid forhandle på nytt.
- La hver interessent injisere arbeid direkte, forbigå produkteieren.

## Hvorfor det har betydning

Å beskytte Sprint-målet er det som gjør Scrum forutsigbar; konstant injeksjon gjør Sprints til kaotiske gjøremålslister.

Håndtering av endring gjennom produkteieren med eksplisitte avveininger holder teamet fokusert samtidig som det forblir responsivt overfor reelle nødssituasjoner.