คุณจัดการกับคำขอเปลี่ยนแปลงขอบเขตในตรงกลาง Sprint ได้อย่างไร

Question

Accepted Answer

ค่าเริ่มต้นใน Scrum คือ **ปกป้อง Sprint Goal**: ไม่ควรเพิ่มการเปลี่ยนแปลงที่อาจเกี่ยวข้องกับมัน แต่ 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.
```

## ตัวอย่างที่เป็นรูปธรรม

ตรงกลาง Sprint ฝ่ายขายต้องการรายงาน "เล็กน้อย" ใหม่ Scrum Master ช่วยให้ทีมและ Product Owner เห็นว่าไม่เร่งด่วน ดังนั้นมันจึงไปที่ด้านบนของ backlog ของ Sprint ถัดไป แทนที่จะทำให้เป้าหมายปัจจุบันหยุดชะงัก

## อันตรายทั่วไป

- การดูดซึมงานเพิ่มเติมอย่างเงียบๆ ทำลาย Sprint Goal และซ่อนมัน
- การพูดว่า "ไม่" เสมอหน้าโดยไม่มีทางออก — Product Owner สามารถเจรจาใหม่ได้เสมอ
- ให้ผู้มีส่วนได้ส่วนเสียทุกคนนำเสนองานโดยตรง โดยไม่สนใจ Product Owner

## ทำไมมันจึงสำคัญ

การปกป้อง Sprint Goal คือสิ่งที่ทำให้ Scrum คาดเดาได้; การฉีดอย่างต่อเนื่องเปลี่ยน Sprints เป็นรายการสิ่งที่ต้องทำที่วุ่นวาย

การจัดการการเปลี่ยนแปลงผ่าน Product Owner ด้วยการแลกเปลี่ยนที่ชัดเจนจะทำให้ทีมมุ่งเน้นและยังคงตอบสนองต่อสถานการณ์ฉุกเฉินจริง