Scrum та невідкладні задачі серед спринта

Усі, хто читав книжки по Scrum'у, знають про правило непорушності обсягу спринта: Усе, що включили до спринт-беклогу на плануванні, має робитись; і не можна допускати жодних змін під час самого спринта!
У той же час усі, хто працював чи намагався працювати по Scrum'у, відчули, що виконання цього правила іноді коштує дуже багато зусиль, а бува - і добрих стосунків із ПО. Особливо важко буває коли треба і підтримувати вже випущений продукт, і одночасно робити нову функціональність.
Повз мене пройшли сотні "Великих Битв за Спринт", де енергійний, щойно просвітлений еджайлом скрам-майстер, зіштовхувався з не дуже начитаним, але дуже переконливим ПО. Часом перемагав скрам-майстер. Він (чи вона) тоді виглядав героєм: тепер команда може працювати без страху, що зараз таски втратять усю бізнесову цінність.
Але коли перемагав ПО, годі було шукати людину більш розгублену, ніж щойно впевнений у майбутньому скрам-майстер. У цьому випадку або треба було скасовувати весь спринт та влаштовувати нове планування, або продовжувати старий "зіпсований" спринт. І тоді лише горбочок на burn-down chart'і щодня нагадував про програний бій.