Si e trajtoni kërkesën për ndryshim të fushës në mes të një Sprint?

Question

Accepted Answer

Parazgjedhja në Scrum është të **mbrojë Qëllimin e Sprint**: nuk duhet shtuar ndryshime që e rrezikojnë atë. Por Scrum nuk është rigjid — fushë mund të *rinegocohet me Product Owner-in*, dhe një ndryshim vërtet urgjent mund të trajtohet, me kompromise të bërë eksplicite.

## Korniza për vendim-marrje

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

## Shembull konkret

Në mes të Sprint, shitjet duan një raport "të vogël" të ri. Scrum Master-i ndihmon ekipin dhe Product Owner-in të shohin se nuk është urgjent, kështu që shkon në krye të backlog-it të Sprint-it të ardhshëm në vend të shqetësimit të qëllimit aktual.

## Grackat e zakonshme

- Thithjen në heshtje të punës shtesë, duke shkatërruar Qëllimin e Sprint dhe fshehjen e tij.
- Të thuash një "jo" të sheshtë pa rrugë — Product Owner-i mund të rinegocohet gjithmonë.
- Lejim për secilin interesent të injektojë punën drejtpërdrejt, duke anashkaluar Product Owner-in.

## Pse ka rëndësi

Mbrojta e Qëllimit të Sprint është ajo që e bën Scrum të parashikueshëm; injektim konstante kthejnë Sprint në lista kaotike të punëve.

Trajtimi i ndryshimit përmes Product Owner-it me kompromise eksplicite e mbën ekipin të fokusuar ndërkohë që qëndron përgjegjës ndaj emergjencave reale.