آپ Sprint کے درمیان میں scope تبدیل کرنے کی درخواست کو کیسے سنبھالتے ہیں؟

Question

Accepted Answer

Scrum میں ڈیفالٹ **Sprint Goal کو محفوظ رکھنا** ہے: کوئی بھی تبدیلی شامل نہیں کی جانی چاہیے جو اسے خطرے میں ڈالے۔ لیکن Scrum سخت نہیں ہے — scope کو *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.
```

## حقیقی مثال

Sprint کے درمیان میں، فروخت کی ٹیم ایک "چھوٹی" نئی رپورٹ چاہتی ہے۔ Scrum Master ٹیم اور Product Owner کو سمجھنے میں مدد دیتا ہے کہ یہ ضروری نہیں ہے، اس لیے یہ اگلے Sprint کے backlog کی ترتیب میں سب سے اوپر جاتا ہے بجائے موجودہ goal کو متاثر کرنے کے۔

## عام غلطیاں

- خاموشی سے اضافی کام کو جذب کرنا، Sprint Goal کو تباہ کرنا اور اسے چھپانا۔
- سادہ طریقے سے "نہیں" کہنا بغیر کسی راستے کے — Product Owner ہمیشہ دوبارہ بات چیت کر سکتا ہے۔
- ہر stakeholder کو براہ راست کام ڈالنے دینا، Product Owner کو نظر انداز کرتے ہوئے۔

## اہمیت

Sprint Goal کو محفوظ رکھنا وہ چیز ہے جو Scrum کو قابلِ پیش گوئی بناتی ہے؛ مسلسل انجکشن Sprints کو افراتفری والی to-do lists میں تبدیل کر دیتی ہے۔

Product Owner کے ذریعے تبدیلی کو سنبھالنا واضح trade-offs کے ساتھ ٹیم کو توجہ مرکوز رکھتا ہے جبکہ حقیقی ایمرجنسیز کے لیے جوابی رہتا ہے۔