আপনি Sprint এর মাঝামাঝিতে স্কোপ পরিবর্তনের অনুরোধ কীভাবে পরিচালনা করেন?

Question

IT Interview Practice · 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 কে বুঝতে সাহায্য করে যে এটি জরুরি নয়, তাই এটি পরবর্তী Sprint এর ব্যাকলগের শীর্ষে যায় বর্তমান লক্ষ্যকে বাধাগ্রস্ত না করে।

## সাধারণ ত্রুটি

- নীরবে অতিরিক্ত কাজ শোষণ করা, Sprint Goal ভেঙে দেওয়া এবং এটি লুকানো।
- কোনো পথ ছাড়াই সরাসরি "না" বলা — Product Owner সর্বদা পুনর্নেগোশিয়েট করতে পারে।
- প্রতিটি স্টেকহোল্ডারকে সরাসরি কাজ ইনজেক্ট করতে দেওয়া, Product Owner কে বাইপাস করে।

## এটি কেন গুরুত্বপূর্ণ

Sprint Goal রক্ষা করা Scrum কে পূর্বাভাসযোগ্য করে তোলে; ক্রমাগত ইনজেকশন Sprints কে বিশৃঙ্খল টু-ডু তালিকায় পরিণত করে।

Product Owner এর মাধ্যমে স্পষ্ট ট্রেড-অফ সহ পরিবর্তন পরিচালনা করা টিমকে মনোনিবেশ রাখে এবং বাস্তব জরুরি পরিস্থিতিতে প্রতিক্রিয়াশীল থাকে।

সিদ্ধান্ত গ্রহণের কাঠামো

বাস্তব উদাহরণ

সাধারণ ত্রুটি

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন