Kaip tvarkote prašymą keisti apimtį per Sprint vidurio?

Question

Accepted Answer

Numatytas Scrum parinktis yra **apsaugoti Sprint tikslą**: nereikėtų pridėti jokių pakeitimų, kurie jį pastatytu į pavojų. Tačiau Scrum nėra standartus — apimtis gali būti *iš naujo susitarta su produkto savininku*, ir iš tiesų skubūs pakeitimai gali būti atliekti, kai mainai yra aiškūs.

## Sprendimo sistema

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

## Konkretus pavyzdys

Sprint viduryje pardavimo skyrius nori "mažo" naujo ataskaitos. Scrum vedėjas padeda komandai ir produkto savininkui suprasti, kad tai nėra skubaru, todėl ji atiduodama į kito Sprint atgal sąrašo viršų, o ne trukdo dabartiniu tikslu.

## Dažnos klaidos

- Tyliai sukviestas papildomas darbas, sugadinti Sprint tikslą ir jį paslėpti.
- Pasakyt tiesą "ne" be kelio — produkto savininkas visada gali iš naujo sutarti.
- Leisti kiekvienam suinteresuotajam tiesiogiai įterpti darbą, aplenkiant produkto savininką.

## Kodėl tai svarbu

Sprint tikslo apsauga yra tai, kas daro Scrum numatoma; nuolatinis susisukimas Sprint-us paverčia chaotiškais darbų sąrašais.

Pakeitimų tvarkymas per produkto savininką su aiškiomis mainais pabrėžia komandą fokusuotą, tuo tarpu lieka atsakinga į tikrus avarijų atvejus.