Wie gehen Sie mit einer Anfrage zur Änderung des Umfangs mitten im Sprint um?

Question

Accepted Answer

Die Standardposition in Scrum ist, das **Sprint Goal zu schützen**: Es sollten keine Änderungen hinzugefügt werden, die es gefährden. Aber Scrum ist nicht starr — der Umfang kann *mit dem Product Owner neu verhandelt werden*, und eine wirklich dringende Änderung kann bewältigt werden, mit explizit gemachten Trade-offs.

## Warum es wichtig ist

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

## Konkretes Beispiel

Mitten im Sprint möchte der Vertrieb einen "kleinen" neuen Bericht. Der Scrum Master hilft dem Team und dem Product Owner zu sehen, dass es nicht dringend ist, daher geht es an die Spitze des Backlogs des nächsten Sprints, anstatt das aktuelle Ziel zu gefährden.

## Häufige Fallstricke

- Stillschweigend zusätzliche Arbeit absorbieren, das Sprint Goal sprengen und es verbergen.
- Ein flaches "Nein" sagen ohne Lösungsweg — der Product Owner kann immer neu verhandeln.
- Jedem Stakeholder erlauben, Arbeit direkt einzuschleusen und dabei den Product Owner umgehen.

## Warum es wichtig ist

Das Sprint Goal zu schützen ist das, was Scrum vorhersehbar macht; ständiges Einschleusen verwandelt Sprints in chaotische To-Do-Listen.

Änderungen durch den Product Owner mit expliziten Trade-offs zu handhaben, hält das Team fokussiert und bleibt gleichzeitig reaktiv gegenüber echten Notfällen.