Hur hanterar du en förfrågan om att ändra omfattning mitt under en Sprint?

Question

Accepted Answer

Standarden i Scrum är att **skydda Sprint-målet**: inga ändringar bör läggas till som riskerar det. Men Scrum är inte stelt — omfattningen kan *omförhandlas med Product Owner*, och en verkligt brådskande ändring kan hanteras, med tydligt uttalade avvägningar.

## Ett beslutsramverk

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

Mitt under Sprint vill försäljningen ha en "liten" ny rapport. Scrum Master hjälper teamet och Product Owner att se att det inte är brådskande, så det går till toppen av nästa Sprints backlog i stället för att störa det aktuella målet.

## Vanliga fallgropar

- Tyst absorbera extra arbete, förstöra Sprint-målet och dölja det.
- Säga ett helt "nej" utan någon väg framåt — Product Owner kan alltid omförhandla.
- Låta varje intressent injicera arbete direkt och förbi Product Owner.

## Varför det är viktigt

Att skydda Sprint-målet är det som gör Scrum förutsägbar; konstant injicering förvandlar Sprints till kaotiska att-göra-listor.

Att hantera förändring genom Product Owner med uttryckliga avvägningar håller teamet fokuserat samtidigt som det förblir responsivt för verkliga nödfall.