كيف تتعامل مع طلب تغيير النطاق في منتصف Sprint؟

Question

Accepted Answer

الافتراضي في Scrum هو **حماية Sprint Goal**: لا يجب إضافة أي تغييرات قد تعرضها للخطر. لكن Scrum ليس جامداً — يمكن *إعادة التفاوض على النطاق مع مالك المنتج*، ويمكن التعامل مع التغيير الحقيقي الطارئ، مع توضيح المقارنات.

## القرار الإطار

```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 الفريق ومالك المنتج على رؤية أنه ليس طارئاً، لذا يذهب إلى أعلى حقول الـ Sprint التالي بدلاً من تعطيل الهدف الحالي.

## الأخطاء الشائعة

- امتصاص العمل الإضافي بصمت، مما يفجر Sprint Goal ويخفيه.
- قول "لا" بشكل قاطع بدون مسار — يمكن لمالك المنتج دائماً إعادة التفاوض.
- السماح لكل صاحب مصلحة بحقن العمل مباشرة، متجاوزاً مالك المنتج.

## لماذا يهم

حماية Sprint Goal هي ما يجعل Scrum متنبأً به؛ الحقن المستمر يحول Sprints إلى قوائم مهام فوضوية.

معالجة التغيير من خلال مالك المنتج مع المقارنات الواضحة تحافظ على تركيز الفريق مع البقاء سريع الاستجابة للحالات الطارئة الحقيقية.