Hvordan håndterer du en anmodning om ændring af scope midt i et Sprint?

Question

Accepted Answer

Standarden i Scrum er at **beskytte Sprint Goal**: der bør ikke tilføjes ændringer, der bringer det i fare. Men Scrum er ikke stivt — scope kan *genforhandles med Product Owner*, og en virkelig urgent ændring kan håndteres med eksplicit udtalte kompromisser.

## 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 Sprintet ønsker salg en "lille" ny rapport. Scrum Master hjælper teamet og Product Owner med at se, at det ikke er presserende, så det går i stedet til toppen af næste Sprints backlog i stedet for at forstyrre det nuværende mål.

## Almindelige faldgruber

- Tavst at absorbere ekstra arbejde, hvilket ødelægger Sprint Goal og skjuler det.
- At sige et fladt "nej" uden en vej frem — Product Owner kan altid genforhandle.
- At lade hver stakeholder direkte injicere arbejde, og bypass Product Owner.

## Hvorfor det betyder noget

At beskytte Sprint Goal er det, der gør Scrum forudsigelig; konstant injektion gør Sprints til kaotiske at-do-lister.

At håndtere ændringer gennem Product Owner med eksplicitte kompromisser holder teamet fokuseret og samtidig responsiv over for rigtige nødsituationer.