Dzisiaj chciałbym zająć się zagadnieniem zakończenia sprintu przed czasem jego trwania. Takie rozwiązanie istnieje i zostało przewidziane przez Scrum framework, zawierający wytyczne, swoisty plan B na tą okoliczność. Jak wiemy z życia przerywanie zaplanowanej wcześniej pracy nie jest dla nikogo czymś pożądanym i nie zdarza/nie powinno się zdarzać często, jednakże mogą zajść okoliczności które będą tego wymagać. Decyzja o przerwaniu sprintu natychmiastowo kończy sprint w trakcie i rozpoczyna kolejny. 
Co może składać się na potencjalną przyczynę, miedzy innymi: nagła zmiana wartości biznesowej pracy którą wykonuje zespół tzn. może ujawnić się praca która jest ważniejsza do wykonania i ma wyższy priorytet na daną chwilę bądź praca która była zaplanowana na iterację traci na ważności, istotności, priorytecie. Wówczas należy podjąć decyzję o przegrupowaniu zakresu prac i kontynuacji w nowych urzeczywistnionych realiach. Kolejnym częstym powodem przerywania sprintu jest nie do szacowanie estymacji pracy na dany sprint. Zespół podczas spotkania sprint planning zgadza się dostarczyć w czasie trwania sprintu zawartość sprint backlog podpisując się pod tym (tzw. sprint commitment) ale w trakcie pracy okazuje się, że niekoniecznie. 

W obliczu tych wydarzeń pojawia się wówczas pytanie kto z zespołu powinien podjąć decyzję o przerwaniu sprintu mając na uwadze nierealność dostarczenia przez zespół całego sprint backlogu? 
Otóż jedyną osobą która może zdecydować o tym jest Produkt Owner. Jako że po decyzji o zabiciu sprintu jest spotkanie sprint planning pod kątem nowej iteracji wobec tego Produkt Owner musi z pełnym zrozumieniem i świadomie podejmować taką decyzję i mieć przygotowany plan B. A zespół powinien zawsze podporządkować się decyzji Produkt Ownera ponieważ Ci ludzie pracują w oparciu o priorytety wyznaczane przez niego.
Najczęstsze powody tego iż sprinty kończą się przedwcześnie niepowodzeniem:

• ubogie user story, zawierające za mało informacji biznesowej bądź niewypełnione kryteriami akceptacji
• mało zgrany zespół lub nie mający wszystkich niezbędnych kompetencji
• bariery komunikacyjne/kulturowe pomiędzy członkami zespołów w kolokacjach
• zespół optymistycznie podszedł do estymacji zakresu sprintu

Dodatkowo trzeba mieć na uwadze aby zaistnienie zakończenia sprintu przed czasem zostało dobrze omówione podczas retrospektywy sprintu. Ważne aby zostały wyciągnięte lessons learned i znaleziona prawdziwa przyczyna takiego stanu rzeczy. Podczas analizy setna problemu możemy posłużyć się analizą Five Why’s pochodzącą z Lean.

A u Was moi Drodzy co jest najczęstszym powodem terminowania sprintów, zapraszam do dyskusji w komentarzach….