ஸ்பிரிண்டின் நடுவில் நோக்கத்தை மாற்றுவதற்கான கோரிக்கையை நீங்கள் எவ்வாறு கையாள்வீர்கள்?

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 ஐயும் இது அவசரம் அல்ல என்று புரியவைக்க உதவுகிறது, எனவே இது தற்போதைய இலக்கை இடையூறு செய்யாமல் அடுத்த Sprint இன் backlog -ன் மேலே செல்கிறது.

## பொதுவான பாதங்கள்

- கூடுதல் வேலையை மௌனமாக உள்வாங்கிக் கொள்ளுதல், Sprint Goal ஐ உடைத்து, அதை மறைத்தல்.
- மார்க்கம் இல்லாமல் "இல்லை" என்று சொல்லலாம் — Product Owner எப்போதும் மீண்டும் பேசிக் கொள்ளலாம்.
- ஒவ்வொரு பங்குதாரரையும் நேரடியாக வேலையைச் செலுத்த அனுமதிக்கிறது, Product Owner ஐ விட்டுவிட்டு.

## இது ஏன் முக்கியம்

Sprint Goal ஐ பாதுகாப்பது Scrum ஐ கணிக்க முடியும் என்பது எது; நிரந்தர ஊசி Sprint களை குழந்தைத் தம் கலவரமாக மாற்றியுள்ளது.

Product Owner மூலம் மாற்றத்தை வெளிப்படையான வர்த்தக-வர்த்தகங்களுடன் கையாளுவது குழுவை கவனம் செலுத்தும் போது உண்மையான அவசரங்களுக்கு பதிலளிக்க வைக்கிறது.