Wydarzenia w Scrumie posiadają pewne ograniczenia. Są to wytyczne dotyczące np. zakresu, uczestników i czasu trwania. W tym wpisie zajmę się tym ostatnim, wydaje się, że najprostszym, bo dokładnie określonym, choć w praktyce często trudnym do utrzymania zagadnieniem. Mam na myśli oczywiście ramy czasowe (z ang. timebox).

Ramy czasowe według Przewodnika po Scrumie

Każde z 5 wydarzeń w Scrumie posiada jasno określony czas trwania, a jest on uzależniony od długości najdłuższego z nich – Sprintu. Poniższa tabela zbiera przedstawione w Przewodniku po Scrumie ramy czasowe dla wydarzeń. 

WydarzenieCzas trwania
SprintMaksymalnie 1 miesiąc
Sprint PlanningMaksymalnie 8 godzin w Sprincie
Sprint ReviewMaksymalnie 4 godziny w Sprincie
Sprint RetrospectiveMaksymalnie 3 godziny w Sprincie
Daily Scrum15 minut
Tab. 1 – Ramy czasowe wg Przewodnika po Scrumie

Jak widać, poza Daily Scrum, wszystkie wydarzenia mają określony maksymalny czas trwania. Wynika to z tego, że Scrum Team sam ustala, jak długi będzie Sprint, biorąc oczywiście pod uwagę wiele czynników. Dla krótszych niż miesiąc iteracji, spotkania będą zazwyczaj pochłaniać mniej czasu. 

Jak przeliczać ramy czasowe na krótkie Sprinty?

Maksymalne granice, o których wspomniałam powyżej da się przeliczyć w dość prosty sposób. Wystarczy, że podzielimy maksymalne wartości na 4, by mieć informacje, ile zajmie to dla pojedynczego tygodnia (przy założeniu, że 1 miesiąc to 4 tygodnie). Następnie należy pomnożyć wynik przez długość Sprintu wyrażoną w liczbie tygodni (np. 3). Jeśli liczysz długość Sprintu w dniach, matematyka pozostaje ta sama ;). Przyjmujesz ile mieści się w jednym miesiącu, a dalsze postępowanie już znasz!

Poniżej przedstawiam tabelę dla standardowego podziału tygodniowego.

WydarzenieCzas trwania*
Sprint4 tygodnie3 tygodnie2 tygodnie1 tydzień
Sprint Planning8 godzin6 godzin4 godziny2 godziny
Sprint Review4 godziny3 godziny2 godziny1 godzina
Sprint Retrospective3 godziny2 godziny 15 minut1,5 godziny45 minut
Daily Scrum15 minut15 minut15 minut15 minut
Tab. 2 – Ramy czasowe dla różnych długości Sprintu

*Warto w tym miejscu podkreślić, że wszystkie czasy trwania wydarzeń innych niż Daily Scrum to wartości umownie przyjęte dla danej długości sprintu. Przewodnik po Scrumie zaznacza, że dla Sprintów krótszych niż miesiąc, spotkania trwają krócej, co nie oznacza, że muszą dokładnie trwać tyle ile w powyższej tabeli. Z własnego doświadczenia polecam trzymania się zaproponowanych ram i ewentualnego drobnego dopasowania ich do potrzeb zespołu. 

Pamiętaj! Gdy praca przeznaczona na dane wydarzenie jest wykonana, powinno się ono zakończyć (to jedno z częstych pytań na egzaminie scrum.org!). 

Po co wyznaczane są ramy czasowe?

Ktoś mógłby zadać pytanie, po co wyznaczać takie ramy, przecież praca i tak musi być wykonana, a każdy zespół wie, ile na to poświęcić czasu. 

Przewodnik po Scrumie wymienia kilka ważnych aspektów powiązanych z czasem trwania wydarzeń:

  • Sprinty „to wydarzenia o ustalonej długości, trwają̨ maksymalnie miesiąc dla uzyskania regularności.”
  • „Kiedy Sprint trwa zbyt długo, Cel Sprintu może się zdezaktualizować, może zwiększyć się złożoność, a ryzyko może wzrosnąć. Krótsze Sprinty można wprowadzić dla uzyskania większej liczby cykli uczenia się oraz ograniczenia ryzyka związanego z kosztami i nakładem pracy do krótszych okresów.”
  • „Wydarzenia są wykorzystywane w Scrumie dla wprowadzenia regularności oraz ograniczenia konieczności organizowania innych, nieujętych w Scrumie spotkań. Optymalnie jest, kiedy wszystkie wydarzenia odbywają się o stałej porze i w tym samym miejscu, aby ograniczyć złożoność.”

W powyższych fragmentach pojawiają się słowa regularność, zdezaktualizować, złożoność, ryzyko, koszty, inne spotkania. Mają one ukierunkować korzystających ze Scruma na spojrzenie na nie przez pryzmat czasu. Każda godzina pracy to koszt, nieproduktywne wydarzenia to brak transparentności, a w konsekwencji wzrost ryzyka niepowodzenia i można by tak wymieniać dalej. Ramy czasowe przede wszystkim mają za zadanie skupić uwagę zespołu na celu spotkań, tak aby osiągnął on ich cele.

Podsumowanie

Wydaje się, że dla 8 developerów 15 minut Daily Scruma to za mało, choć wiele zespołów dobrze sobie z tym radzi. Nic się nie stanie, gdy Daily potrwa 16 minut, gdy jest to potrzebne do osiągnięcia celu spotkania, ale należy uważać by nagle z tego nie zrobiło się ich 30 :). Czasy wydarzeń to, jak sam Scrum, ramy, które mają pomagać maksymalizować wartość wytwarzanego produktu. Razem z określonymi celami i przebiegiem dają znakomity przepis na sukces.


Sprawdź nasze ostatnie wpisy: