तपाईले Sprint को बिचमा scope परिवर्तन गर्न को लागि अनुरोध कसरी संभाल्नुहुन्छ?

Question

Accepted Answer

Scrum मा डिफल्ट भनेको **Sprint Goal लाई सुरक्षित राख्नु** हो: यसलाई खतरामा पारने कुनै पनि परिवर्तन थपिनु हुँदैन। तर Scrum कठोर छैन — scope लाई *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.
```

## ठोस उदाहरण

Sprit को बिचमा, बिक्रय टीमले "सानो" नयाँ रिपोर्ट चाहन्छ। Scrum Master ले टीम र Product Owner लाई यो आपतकालीन छैन भनेर बुझ्न मद्दत गर्छ, त्यसैले यो अर्को Sprint को backlog को शीर्षमा जान्छ वर्तमान लक्ष्यलाई बाधा पार्नुको सट्टा।

## साधारण गल्तीहरू

- चुपचाप अतिरिक्त काम समेट्नु, Sprint Goal लाई विस्फोट गर्नु र यसलाई लुकाउनु।
- कुनै पथ बिना सपाट "छैन" भन्नु — Product Owner सधैं पुनः वार्ता गर्न सक्छ।
- हरेक स्टेकहोल्डरलाई सीधा काम इञ्जेक्ट गर्न दिनु, Product Owner लाई बाइपास गर्दै।

## किन यो महत्त्वपूर्ण छ

Spring Goal लाई सुरक्षित राख्नु भनेको Scrum लाई पूर्वानुमानीय बनाउनु हो; निरन्तर इञ्जेक्शनले Sprints लाई अराजक गर्न सूचीमा परिणत गर्छ।

Product Owner को माध्यमबाट परिवर्तन सँग स्पष्ट सम्झौता संभाल्नु टीमलाई केन्द्रित राख्छ जबकि साँच्चिकै आपतकालीन स्थितिमा प्रतিक्रियाशील रहन्छ।