आप स्प्रिंट के बीच में स्कोप बदलने के अनुरोध को कैसे संभालते हैं?

Question

Accepted Answer

Scrum में डिफ़ॉल्ट है **Sprint Goal को सुरक्षित रखना**: कोई भी परिवर्तन नहीं जोड़ना चाहिए जो इसे जोखिम में डाले। लेकिन Scrum कठोर नहीं है — **Product Owner** के साथ स्कोप को *फिर से बातचीत* किया जा सकता है, और एक वास्तविक आवश्यक परिवर्तन को संभाला जा सकता है, स्पष्ट trade-offs के साथ।

## निर्णय लेने की रूपरेखा

```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 को यह देखने में मदद करता है कि यह जरूरी नहीं है, इसलिए यह मौजूदा लक्ष्य को बाधित करने के बजाय अगले स्प्रिंट के backlog के शीर्ष पर जाता है।

## सामान्य गलतियाँ

- चुप्पी से अतिरिक्त काम को अवशोषित करना, Sprint Goal को तोड़ना और इसे छिपाना।
- किसी रास्ते के बिना सपाट "नहीं" कहना — Product Owner हमेशा फिर से बातचीत कर सकता है।
- हर हितधारक को सीधे काम इंजेक्ट करने देना, Product Owner को दरकिनार करते हुए।

## यह क्यों महत्वपूर्ण है

Sprint Goal की रक्षा करना वह है जो Scrum को पूर्वानुमान योग्य बनाता है; लगातार इंजेक्शन Sprints को अराजक to-do सूचियों में बदल देता है।

Product Owner के माध्यम से परिवर्तन को संभालना स्पष्ट trade-offs के साथ टीम को केंद्रित रखता है जबकि असली आपातकाल के लिए प्रतिक्रिया शील रहता है।