როგორ მოაგვარებთ დეკემბრის შუაგულში scope-ის ცვლილების მოთხოვნას?

Question

Accepted Answer

Scrum-ში ნაგულისხმი მნიშვნელობა არის **Sprint Goal-ის დაცვა**: არ უნდა დაემატოს ის ცვლილებები, რომლებიც მას საფრთხეს უქმნიან. მაგრამ Scrum არ არის მკაცრი — scope შეიძლება *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-ის გარეშე აშკარა ტრეიდ-ოფ-ებით უზრუნველყოფს, რომ გუნდი ფოკუსირებული რჩება, ხოლო რეაგირებს ნამდვილი ჩრდილოვანი გარემოებებზე.