Когато Спринтът се счупи по средата на седмицата: Практическа адаптация
Един Спринт може да се отклони от курса. Научете как да инспектирате и адаптирате по средата на Спринта, без да изоставяте принципите на Scrum. Практически стъпки за възстановяване и учене.
Понякога един Спринт се обърква. Критична зависимост се проваля. Появява се нов, спешен проблем. Работата, планирана по време на Sprint Planning, става невъзможна или неактуална. Не можете просто да я игнорирате. Scrum е свързан с емпиричен контрол на процесите. Това означава инспекция и адаптация. Когато един Спринт се счупи по средата на седмицата, това е критичен момент за Scrum екипа да приложи тези принципи. Не всеки проблем изисква спиране на Спринта. Но някои го изискват. Разбирането на разликата и как да се действа е ключът към поддържането на гъвкавост и доставянето на стойност.
Разпознаване на счупен Спринт
Един Спринт е наистина счупен, когато неговата Sprint Goal стане остаряла или непостижима. Това не е свързано с леко изоставане от графика. Става въпрос за фундаментална промяна. Scrum Guide посочва, че Sprint Goal е единствената цел за Спринта. Ако тази цел вече не е жизнеспособна или ако външно събитие налага толкова значителна промяна, че прави текущия план безполезен, тогава Спринтът е счупен. Това често се случва поради непредвидени външни фактори, а не само поради лошо планиране.
Ролята на Product Owner
Product Owner има правомощието да отмени Спринт. Това е сериозно решение и трябва да се случва рядко. То се случва, когато Sprint Goal стане остаряла. Само Product Owner може да вземе това решение. Ако един Спринт бъде отменен, всички завършени и „Done“ елементи от Product Backlog се преглеждат. Тези, които са „Done“, могат да бъдат доставени. Частично завършените елементи се преоценяват и се връщат в Product Backlog. След това екипът незабавно преминава към нов Sprint Planning, за да започне нов Спринт.
Кога да не се отменя: Адаптиране на Sprint Backlog
Отмяната е крайна мярка. Повечето проблеми по средата на Спринта не я изискват. Developers управляват Sprint Backlog. Те могат да инспектират напредъка си към Sprint Goal по време на Daily Scrum. Ако установят, че не могат да постигнат Sprint Goal, те работят с Product Owner, за да предоговорят обхвата на Sprint Backlog. Самата Sprint Goal не се променя. Developers могат да включат нови елементи или да премахнат съществуващи, за да постигнат най-добре Sprint Goal. Това е нормална част от адаптацията в рамките на един Спринт.
Разгледайте тези сценарии, при които адаптацията е по-подходяща от отмяната:
- Ключова зависимост е забавена, но има друга работа, която все още може да допринесе за Sprint Goal.
- Открита е критична грешка и отстраняването ѝ е в съответствие със Sprint Goal или е необходимо предварително условие.
- Екипът осъзнава, че даден елемент е по-сложен от очакваното и няма да се побере, но други елементи могат да бъдат завършени.
- Нова информация променя приоритета на някои елементи, но цялостната Sprint Goal остава валидна.
Включване на целия Scrum екип
Вземането на решения относно счупен Спринт е съвместно усилие. Developers са най-близо до работата и разбират техническите последици. Product Owner разбира стойността и пазарния контекст. Scrum Master помага за улесняване на тези дискусии и гарантира спазването на принципите на Scrum. Те ръководят екипа при вземането на прозрачни решения, базирани на емпирични данни. Това може да включва импровизирана среща за обсъждане на опции, отделно от Daily Scrum.
Учене от прекъсването
Независимо дали отменяте или адаптирате, всяко прекъсване по средата на Спринта е възможност за учене. Sprint Retrospective е мястото за обсъждане на случилото се. Защо Спринтът се счупи или изискваше значителна адаптация? Какво екипът би могъл да направи по различен начин? Какви промени в процеса могат да предотвратят подобни проблеми в бъдеще? Този начин на мислене за непрекъснато подобрение е в основата на Scrum. Не просто отстранявайте непосредствения проблем. Разберете основната му причина и подобрете начина си на работа.
Счупеният Спринт не е провал на Scrum. Това е възможност да демонстрирате гъвкавост. Чрез инспектиране на ситуацията и адаптиране на плана или дори на самия Спринт, Scrum екипът показва своя ангажимент за доставяне на стойност и реагиране на промени. Използвайте тези моменти, за да засилите способността на вашия екип да се справя ефективно с несигурността.