Wydarzenia scrumowe: Sprint (1)

Fundamentem Scruma jest empiryzm, którego filarami są przejrzystość, inspekcja i adaptacja. Sprint jest jednym z 5 wydarzeń scrumowych, które umożliwiają realizowanie pracy w oparciu o te filary. Każde wydarzenie scrumowe daje możliwość inspekcji i adaptacji, a ich celem jest stworzenie warunków do uzyskania wymaganej przejrzystości.

O sprincie słów parę

[1] Jednym z pięciu wydarzeń zdefiniowanych w Scrumie jest Sprint. Jest to nietypowe wydarzenie będące kontenerem na pozostałe 4 wydarzenia (PlanowanieDailyReview i Retrospektywa). Cała praca wykonywana jest w Sprintach.

Sensem Sprintów jest przekształcanie hipotez w ukończone Przyrosty Produktu, które za pomocą wdrożenia można przekuć w wartość [3]. Każdy Sprint powinien mieć pojedynczy Cel Sprintu, który będzie wspierać skupienie Zespołu.

Sprint jest istotą Scruma. Podobnie jak pozostałe wydarzenia, Sprint daje możliwość inspekcji i adaptacji. Dzięki cykliczności Sprintów, Product Owner może często weryfikować, czy to co jest realizowane zbliża do uzyskania Celu Produktu i przynosi wartość. Wyniki inspekcji można wykorzystać w kolejnym Sprincie do adaptacji kierunku rozwoju.

Taka cykliczność umożliwia empiryczne podejście do tworzenia Produktu. Dzięki niemu schemat pracy jest przewidywalny [4]. Jest sposobem na ograniczenie ryzyka strat, związanych z realizowaniem niepotrzebnych Produktów czy ich funkcjonalności. Umożliwia szybkie i zwinne dostosowanie się do zmieniających się warunków rynkowych.

Długość Sprintu

Sprinty mają stałą długość i trwają maksymalnie miesiąc.

Długość Sprintu powinna odpowiadać na potrzeby Zespołu oraz środowiska, w którym tworzony jest Produkt. Sprint powinien być odpowiednio długi by umożliwić utworzenie ukończonego Przyrostu [3] (zgodnie z Definicją Ukończenia, ang. Definition of Done, DoD), oraz możliwie krótki, by utrzymać możliwości zwinnej adaptacji do zmieniających się warunków. Najczęściej spotykane są sprinty o długości 2-3 tygodni.

Po ukończeniu jednego Sprintu od razu zaczyna się kolejny.

Po co Product OwneroWi sprint?

Istotą Sprintu jest odpowiednio częsta inspekcja wyników wykonywanej pracy oraz warunków środowiska. Dzięki cykliczności Product Owner ma możliwość okresowego sprawdzania czy tworzony Produkt przynosi wartość. Regularnie uzyskuje nowe informacje, które pozwalają mu podejmować lepsze decyzje maksymalizujące wartość Produktu.

Praca zorganizowana wokół Celu Sprintu

W trakcie sprintu nie powinno się dokonywać żadnych zmian, które zagrażałyby osiągnięciu przez Zespół Celu Sprintu. Cel ten powinien być świętością, zarówno dla Developerów jak i dla Product Ownera. Jest to pewnego rodzaju umowa, będąca drogowskazem, co w danym momencie jest najważniejsze i jakie działania przybliżają do osiągnięcia Celu Produktu. W duchu szacunku, Product Owner nie powinien w trakcie Sprintu zmieniać zakresu pracy Developerów, czy dorzucać dodatkowych zadań rozpraszających Zespół.

Na Cel Sprintu można utworzyć osobny element Product Backlogu / Sprint Backlogu z własnymi Kryteriami akceptacji (co musi być spełnione produktowo, by Cel mógł być uznany za osiągnięty). Ułatwia to komunikację z Developerami i eliminuje potencjalną niejednoznaczność Celu.

Jeżeli w trakcie Sprintu pojawiają się nowe informacje, to wraz z rosnącym zrozumieniem sytuacji, zakres pracy może być doprecyzowywany lub renegocjowany z Product Ownerem.

Jakość dostarczanych w Sprintach Przyrostów nie powinna spadać [3]. Zespół nie powinien iść na skróty i ryzykować jakością dostarczonego Produktu, tylko po to by osiągnąć Cel Sprintu. I choć dla Product Ownera kuszące może być pokazanie na Review ukończonego Przyrostu, to jednak takie działanie nie byłoby w zgodzie z wartościami Scruma – odwagą, otwartością i szacunkiem.

W trosce o Product Backlog

W trakcie Sprintu powinien znaleźć się czas, aby zadbać o uszczegóławianie Product Backlogu. Dzieje się to na ogół podczas tzw. Refinementów. Product Owner, jako osoba odpowiedzialna za zarządzanie Product Backlogiem, powinna zadbać o to by spotkania odbywały się cyklicznie, a Product Backlog był gotowy na 1-2 sprinty do przodu.

Anulowanie Sprintu

Product Owner jest jedyną osobą uprawnioną do anulowania Sprintu. [1, 6] Sprint może zostać przerwany, tylko i wyłącznie w sytuacji, w której Cel Sprintu staje się nieaktualny. Sytuacja taka może się zdarzyć, gdy drastycznie zmienią się warunki rynkowe, a organizacja bez zwłoki postanowi się do nich dostosować. Wymusi to konieczność zmiany Celu Produktu, powodując dezaktualizacje bieżącego Celu Sprintu.

[6] W takiej sytuacji Product Owner może zaakceptować elementy Sprint Backlogu, które spełniają Definicję ukończenia (DoD), a resztę elementów przywrócić do Backlogu Produktu. Następny Sprint zaczyna się zaraz po decyzji o zakończeniu obecnego Sprintu.

Anulowanie Sprintu zdarza się jednak niezmiernie rzadko. Sprinty są celowo krótkie, by umożliwiać zwinne adaptowanie się do zmieniających się warunków, natomiast przerwanie Sprintu wprowadziłoby wiele zamieszania – konieczności przegrupowania, zorganizowania nowych wydarzeń, zmianę kadencji Sprintu oraz szybkiego zaplanowania nowej pracy.

Osobiście nigdy nie podjęłam decyzji o anulowaniu Sprintu.

Podsumowanie

Wydarzenia scrumowe umożliwiają realizowanie empiryzmu poprzez jego trzy filary. Jednak implementacja tych wydarzeń to nie wszystko – by zyskać jak najwięcej korzyści płynących ze Scruma, ważne jest by każdy członek Zespołu rozumiał jakie możliwości przynosi każde z realizowanych wydarzeń, i jak przyczyniają się one do empiryzmu całego procesu. Istotą Sprintu jest odpowiednio częsta inspekcja wykonywanej pracy oraz warunków środowiska. Działania te są kluczowe dla empiryzmu.

Bibliografia

[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

[2] Unlock the Power in the Five Scrum Events; https://www.scrum.org/resources/blog/unlock-power-five-scrum-events

[3] The Purpose of the Five Scrum Events; https://www.scrum.org/resources/blog/purpose-five-scrum-events

[4] How leaders can effectively support and leverage Scrum Events; https://www.scrum.org/resources/blog/how-leaders-can-effectively-support-and-leverage-scrum-events

[5] The Order of Events in Scrum Matters; https://www.scrum.org/resources/blog/order-events-scrum-matters

[6] Sprint Cancellation; https://www.scrum.org/resources/sprint-cancellation

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *