તમે સ્પ્રિન્ટની મધ્યમાં સ્કોપ બદલવાની વિનંતી કેવી રીતે સંભાળો છો?

Question

Accepted Answer

Scrum માં ડિફોલ્ટ એ છે કે **સ્પ્રિન્ટ ગોલને સુરક્ષિત રાખવું**: કોઈ પણ ફેરફાર ઉમેરવો જોઈએ નહીં જે તેને જોખમમાં મૂકે. પરંતુ Scrum કઠોર નથી — **Product Owner** સાથે સ્કોપ *ફરીથી વાટાઘાટ* કરી શકાય છે, અને સાચું જરૂરી ફેરફાર સંચાલિત કરી શકાય છે, સ્પષ્ટ ટ્રેડ-ઓફ સાથે.

## નિર્ણય માટેનું માળખું

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

## ઠોસ ઉદાહરણ

સ્પ્રિન્ટની મધ્યમાં, વેચાણ દળ એક "નાનું" નવું રિપોર્ટ ઈચ્છે છે. Scrum Master ટીમ અને Product Owner ને તે જોવામાં મદદ કરે છે કે તે ટાળી શકાય તેવું નથી, તેથી તે હાલના ગોલને વિક્ષેપ કરવાને બદલે આગલી સ્પ્રિન્ટના બેકલોગની ટોચ પર જાય છે.

## સામાન્ય ખામીઓ

- ચુપચાપ વધારાનું કાર્ય સમજી લેવું, સ્પ્રિન્ટ ગોલને ભાંગી નાખવું અને તેને છુપાવવું.
- કોઈ પણ પાથ વગર સપાટ "ના" કહેવું — Product Owner હમેશા પુનઃ વાટાઘાટ કરી શકે છે.
- દરેક હિતધારકને કાર્ય સીધા ઇનજેક્ટ કરવાની મંજૂરી આપવી, Product Owner ને અવગણીને.

## તે શા માટે મહત્વપૂર્ણ છે

સ્પ્રિન્ટ ગોલને સુરક્ષિત રાખવું તે છે જે Scrum ને અનુમાનિત બનાવે છે; સતત ઇંજેક્શન સ્પ્રિંટને અસ્તવ્યસ્ત કામની સૂચીમાં ફેરવે છે.

Product Owner માધ્યમથી ફેરફાર સંચાલવું સ્પષ્ટ ટ્રેડ-ઓફ સાથે ટીમને કેન્દ્રિત રાખે છે અને વાસ્તવિક કટોકટી માટે પ્રતિક્રિયાશીલ રહે છે.