Cum gestionezi o cerere de schimbare a scopului în mijlocul unui Sprint?

Question

Accepted Answer

Standardul în Scrum este **protejarea Obiectivului Sprint-ului**: nu trebuie adăugate modificări care să-l pună în pericol. Dar Scrum nu este rigid — scopul poate fi *renegociat cu Product Owner-ul*, iar o schimbare cu adevărat urgentă poate fi gestionată, cu compromisuri explicite.

## Un cadru de decizie

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

## Exemplu concret

La mijlocul Sprint-ului, vânzările doresc un "mic" raport nou. Scrum Master-ul ajută echipa și Product Owner-ul să înțeleagă că nu este urgent, deci merge în vârful backlog-ului următorului Sprint în loc să perturbeze obiectivul curent.

## Capcane comune

- Absorbirea în tăcere a muncii suplimentare, distrugerea Obiectivului Sprint-ului și ascunderea acesteia.
- Spunerea unui "nu" categoric fără cale — Product Owner-ul poate oricând renegocia.
- Permiterea fiecărui stakeholder să injecteze muncă direct, ocolind Product Owner-ul.

## De ce conteaza

Protejarea Obiectivului Sprint-ului este ceea ce face Scrum previzibil; injecția constantă transformă Sprint-urile în liste de lucru haotice.

Gestionarea schimbării prin Product Owner cu compromisuri explicite menține echipa focalizată, rămânând receptivă la urgențe reale.