Co dzieje się w Sprincie i kiedy?

Udane wdrożenie Scruma obejmuje szereg ważnych ceremonii. Należą do nich Sprint Planning, Sprint Review, Daily Scrum, Sprint Retrospektywa i wiele innych.

Często pojawiają się niejasności co do tego, kto powinien uczestniczyć w których ceremoniach Scrum, kiedy się odbywają, jak długo powinny trwać, jaki jest cel danej ceremonii itp.

W tym artykule staramy się wyjaśnić te niejasności:

Sprint Planning

Gdy Sprint się zaczyna, przeprowadzane jest też Sprint Planning. Oficjalnie oznacza to start Sprintu.

Cały zespół Scrum uczestniczy w Sprint Planningu; tzn. zarówno zespół developerski, jak i Scrum Master i Product Owner. W rzadkich przypadkach w tym evencie mogą uczestniczyć też inne osoby, jeśli Product Owner i zespół developerski uznają to za stosowne. Na przykład, jeśli w nadchodzącym Sprincie ma być rozwijana funkcjonalność, którą najlepiej wyjaśni ekspert domenowy (który nie jest jednocześnie Product Ownerem), może być pomocna jego obecność podczas Planningu. W większości przypadków jednak najrozsądniej jest, gdy dyskusje te są prowadzone poza właściwym spotkaniem Planning.

 Długość Sprint Planningu jest proporcjonalna do długości Sprintu. Przy czterotygodniowym Sprincie Planning nie powinien trwać dłużej niż osiem godzin; przy jednotypodniowym Sprincie nie dłużej niż dwie godziny – czyli maksymalnie dwie godziny na tydzień Sprintu.

To ograniczenie do maksymalnego czasu trwania spotkania nazywa się Time Boxingiem. Zalecam zespołom, aby starały się zakończyć Sprint Planning w mniej więcej połowie dozwolonego maksymalnego Time Boxa.

Jako input do Sprint Planningu Scrum Master wnosi informacje o średniej i aktualnej Velocity (prędkości pracy). Product Owner wnosi Product Backlog lub przynajmniej Backlog Items o najwyższym priorytecie do Planningu. W niektórych zespołach Product Owner przedstawia też podczas Planningu wstępny cel Sprintu, który może być następnie wspólnie z zespołem dopracowywany w trakcie Planningu.

Wynikiem Sprint Planningu jest lepiej poinformowany i lepiej przygotowany na nadchodzące prace zespół. Kolejnymi wynikami Planningu są Sprint Backlog i wspólnie stworzony cel Sprintu.

Daily Scrum / Daily Standup

Daily Scrum – zwany też Daily Standupem – to krótka ceremonia odbywająca się każdego dnia, podczas której członkowie zespołu synchronizują się w zakresie swojej pracy. Dzięki Daily Scrumom zapewnia się, że właściwe osoby we właściwym czasie pracują nad właściwymi rzeczami.

Każdego dnia każdy członek zespołu odpowiada na następujące trzy pytania:

1. Co zrobiłem wczoraj w kierunku osiągnięcia celu Sprintu?

2. Co zrobię dzisiaj w kierunku osiągnięcia celu Sprintu?

3. Czy mam przeszkody/problemy, które mi w tym przeszkadzają, a jeśli tak, jakie?

Pytania te mogą być formułowane na różne sposoby. Niektóre zespoły wolą na przykład opisywać, co osiągnęły, zamiast co zrobiły.

Uczestnikami powinni być Scrum Master, zespół developerski, a moim zdaniem również Product Owner.

W społeczności Scrum toczą się dyskusje na temat tego, czy Product Owner powinien uczestniczyć w Daily Scrumie, czy nie. Pozwolenie Product Ownerowi na nieuczestniczenie w Daily Standupie może go zbyt bardzo odizolować od zespołu. Mentalność „my kontra oni" już i tak istnieje w zbyt wielu organizacjach. Nie potrafię wyobrazić sobie, dlaczego Scrum Team lub jego Product Owner chciałby jeszcze bardziej wzmacniać to negatywne nastawienie.

Daily Scrumy są ograniczone do maksymalnie 15 minut. Celem Daily Scruma jest krótka synchronizacja zespołu. W przeciwieństwie do Sprint Planningu nie zalecam tu kończenia w połowie przewidzianego czasu. Dla większości zespołów 5-7 minut po prostu nie wystarczy, aby poruszyć prawdziwe problemy lub zrozumieć, jakie prace zostały wykonane. Jeśli Daily Scrumy są zbyt skrócone, szybko stają się rutyną z wypowiedziami takimi jak „Wczoraj zrobiłem XY. Dziś zrobię to i tamto. Nie mam żadnych impedimentów."

Nie ma formalnych wyników Daily Scrumów, poza lepszą koordynacją prac w zespole developerskim.

Sprint Review

Sprint Review odbywa się ostatniego dnia Sprintu. Product Owner, Scrum Master i zespół developerski powinni być obecni, a także odpowiedni Interesariusze. To, którzy interesariusze powinni być obecni, zmienia się ze Sprintu na Sprint i zależy od tego, co zostało dostarczone w Sprincie.

Sprint Review ma Time Box do maksymalnie czterech godzin dla czterotygodniowego Sprintu. Odpowiednio krótsze są Time Boxy dla krótszych Sprintów, np. godzina dla jednotypodniowego Sprintu.

W Sprint Review należy pokazać wszystkie Product Backlog Items spełniające Definition of Done. Oznacza to, że nie pokazuje się prac, nad którymi jeszcze trwają prace, które nie są jeszcze ukończone. Oczywiście czasem może mieć sens zrobienie wyjątku od tej zasady.

Demonstracja ukończonych funkcjonalności jest centralną aktywnością typowego Sprint Review Meeting. Większość zespołów poświęca jednak też czas na omówienie postępów i ewentualnych problemów.

Celem Review Meeting jest zbieranie informacji zwrotnych na temat rzeczy opracowanych podczas Sprintu. Product Owner przyjmuje wszelkie informacje zwrotne i może na ich podstawie w razie potrzeby dostosować Product Backlog. Wynikiem Sprint Review jest więc zrewidowany Product Backlog.

Sprint Retrospektywa

W Sprint Retrospektywie członkowie zespołu mają okazję zastanowić się, jak mogą ulepszyć swój sposób pracy. Może to na przykład oznaczać, że chcą zmienić sposób wdrażania Scruma, a następnie np. dostosować długość Sprintu. Retrospektywa może jednak też obejmować ogólne aspekty współpracy, takie jak np. nieplanowanie spotkań rano lub ustalenie, które tematy można omawiać na Slacku, a które powinny być wyjaśniane w bezpośredniej rozmowie.

W Sprint Retrospektywie powinien uczestniczyć cały zespół – tzn. zespół developerski, Scrum Master i Product Owner. Wszystko inne prowadziłoby jedynie do podziałów w zespole. Dobry zwinny zespół powinien unikać wszelkich zachowań, które prowadzą do mentalności „my kontra oni".

Oprócz chęci doskonalenia Sprint Retrospektywa nie wymaga żadnego dodatkowego inputu. Wynikiem Retrospektywy powinna być lista zmian lub propozycji usprawnień, które zespół chce wdrożyć.

Time Box dla Retrospektywy wynosi maksymalnie 3 godziny. Czasami może trwać nieco dłużej, ale w większości przypadków zespoły kończą ją w mniej niż godzinę.

Product Backlog Refinement

 Product Backlog Refinement ma zapewnić, że Items na górze Backlogu są gotowe do następnego Sprintu. Może to oznaczać dodawanie szczegółów do istniejących Items, szacowanie, usuwanie niektórych Items, restrukturyzację priorytetów, dzielenie Backlog Items na mniejsze Items lub tworzenie nowych Items.

Choć Refinement Backlogu sam w sobie jest konieczny, nie oznacza to, że zespół musi to robić jako oficjalną ceremonię lub że musi to robić w każdym Sprincie. Większość zespołów przeprowadza jednak regularne spotkania Backlog Refinement, zazwyczaj raz na Sprint lub tydzień.

Dobra wytyczna jest taka, że zespół nie powinien przeznaczać więcej niż 10% całkowitego dostępnego czasu na Backlog Refinement – zarówno na samym spotkaniu, jak i w późniejszych dyskusjach z niego wynikających.

W większości zespołów zarówno wszyscy członkowie zespołu developerskiego, jak i Product Owner i Scrum Master uczestniczą w spotkaniach. O ile zespół nie szacuje Product Backlog Items podczas swoich Refinement Meetings, myślę, że mniej więcej połowa do dwóch trzecich nakładu pracy na development wystarczy i spotkanie może być dla zespołu jak najkrótsze.

Jedyne, co należy wnieść do Refinementu, to górne Items Product Backlogu. Wynikami Refinementu są mniejsze Product Backlog Items, które lepiej nadają się do następnego Sprintu, oraz lepsze zrozumienie niektórych Product Backlog Items.

Szacowanie Backlogu

Jak wspomniano powyżej, wiele zespołów szacuje swoje Product Backlog Items już podczas Refinement Meeting. To jest ideał i jeśli to możliwe, cały zespół developerski uczestniczy w Backlog Refinemencie.

Jeśli tylko część zespołu uczestniczy w Refinemencie, członkowie zespołu spotykają się raz na Sprint, aby oszacować wszystkie nowe prace, dla których Product Owner potrzebuje oszacowania.

W większości zespołów te spotkania szacowania powinny być jak najkrótsze. Zespoły nie powinny bowiem ani generować zbyt wielu nowych Product Backlog Items, ani otrzymywać zalewu nowych Items z zewnątrz. Prace do oszacowania powinny być albo bardzo ważne, albo nowe, albo istniejące Items, które zostały podzielone, aby lepiej pasować do nadchodzącego Sprintu.

Chętnie przeprowadzam szacowanie Product Backlogu bezpośrednio po Daily Scrumie i kilka dni przed końcem Sprintu. To wystarczająco późno, by większość nowych Items była już zidentyfikowana, i wystarczająco wcześnie dla Product Ownera, by mógł zmienić priorytety na podstawie nowych informacji ze szacowań.

Nie zalecam nie szacować Items podczas Sprint Planningu. Wtedy jest bowiem za późno dla Product Ownera na zmianę priorytetów na podstawie szacowań. Prowadzi to też do tego, że członkowie zespołu spędzają więcej czasu na szacowaniu, niż powinni. Zatem szacowanie Product Backlog Items nie podczas Sprint Planningu.

Priorytetyzacja

Przed rozpoczęciem nowego Sprintu Product Owner upewnia się, że wszystkie Items na górze Product Backlogu zostały spriorytetyzowane. Według Oxford American Dictionary priorytetyzować znaczy: „porządkować zadania, problemy itp. według ich ważności, tak aby móc zająć się najpierw najważniejszymi".

Oznacza to, że nie wystarczy powiedzieć: „Wszystkie będą potrzebne". Albo jak pewien Product Owner powiedział mi kiedyś: „Nie bez powodu nazywają się wymaganiami; bo są wymagane".

W większości przypadków nie będzie oficjalnej ceremonii priorytetyzacji. To raczej coś, co Product Owner robi samodzielnie po rozmowach z interesariuszami w celu wyjaśnienia ich potrzeb i życzeń.

Priorytetyzacja powinna odbywać się jak najpóźniej w Sprincie, ale powinna być zakończona przed rozpoczęciem następnego Sprintu. Może to często oznaczać, że jest przeprowadzana jednego z dwóch ostatnich dni Sprintu.

Priorytetyzacja zazwyczaj nie jest szczególnie czasochłonna, ponieważ Product Owner zazwyczaj nanosi poprawki w trakcie Sprintu na podstawie nowych spostrzeżeń, zamiast od początku szczegółowo priorytetyzować cały Backlog.

Spotkania w Sprincie

Jak widać, w Scrumie istnieje szereg ważnych ceremonii, które należy starannie przeprowadzać. Mam nadzieję, że ten artykuł dał Ci lepszy przegląd i pomógł osiągnąć większą jasność w codziennym życiu z Twoim Scrum Teamem. Jeśli chcesz dowiedzieć się więcej, nasze Szkolenia Scrum są właśnie dla Ciebie.

Niniejszy artykuł pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.