Czas trwania wydarzeń Scrum

Jednym z typowych zarzutów wysuwanych w kierunku Scruma jest czas trwania wydarzeń. “Bo w tym Scrumie to tylko spotkania i spotkania, a nie ma kiedy robić!” A jak wygląda to naprawdę?

Narzut, czyli czas trwania wydarzeń Scrum

Tematem czasu trwania wydarzeń w naszej ulubionej metodyce ostatnio zajmowaliśmy się dawno, bo w grudniu 2017. To wtedy opublikowaliśmy film #scrumoverhead w którym przy pomocy skomplikowanych matematycznych obliczeń pokazaliśmy, że wydarzenia Scrum mogą zająć do 12% czasu przewidzianego na Sprint.

Skąd ta liczba? Podręcznik podaje maksymalny czas trwania wydarzeń dla Sprintów trwających miesiąc. Nie ma więc problemu, żeby wszystkie je zsumować i przeliczyć. Z kolei dla krótszych iteracji założyliśmy, że wszystkie wydarzenia, poza Daily Scrumem, są proporcjonalnie krótsze. Ten ostatni zaś występuje raz dziennie i zawsze trwa do 15 minut. Tak więc, jeżeli pojawia nam się kolejny Daily Scrum, to zawsze idzie to w parze z kolejnym dniem pracy.

Jak by nie liczyć, wychodzi nam około dwunastu procent czasu. Chociaż trzeba przyznać, że poczyniliśmy w naszych obliczeniach duże i prawie nieuzasadnione założenie.

“For shorter Sprints, the event is usually shorter.” – Scrum Guide

Nigdzie w materiałach źródłowych nie pada nawet sugestia proporcjonalności. Komentarz zawsze wygląda tak, jak ten zacytowany powyżej. Jednak z naszego doświadczenia wynika, że proporcja świetnie sprawdza się w praktyce. Możemy traktować ją więc jako użyteczną heurystykę. Jeżeli przy miesiącu Sprint Planning może zająć do ośmiu godzin, to przy dwóch tygodniach nie powinien zająć więcej niż cztery.

A w praktyce pewnie i tak zajmie o wiele mniej czasu.

Timebox czyli maksymalny czas trwania wydarzeń

Wszystkie powyższe rozważania nie biorą pod uwagę czegoś, co nazywa się timebox i co zbija argumenty narzekaczy. Ostatnio nagraliśmy nawet na ten temat film na naszym kanale na YouTube. Z jakiegoś powodu poświęcamy tyle uwagi na to “pudełko czasu”, jak swego czasu nazwał je Łukasz.

Timebox to nic innego jak maksymalny czas trwania każdego wydarzenia. Z jednej strony – jeżeli skończymy je wcześniej, to nie siedzimy i nie marnujemy czasu. Ale timebox oznacza też rozejście się o ustalonym czasie, nawet jeżeli nie zdążyliśmy zrealizować celu spotkania. Trudno, musimy się przewrócić, żeby się nauczyć. Wnioski wyciągniemy na kolejnym Sprint Retrospective.

Warto w tym momencie zaznaczyć, że timeboxowanie nie dotyczy samego Sprintu. Mówiliśmy o tym wielokrotnie i będziemy to powtarzać do znudzenia. Długość Sprintu jest stała i nie powinniśmy jej wydłużać lub skracać w zależności od naszego widzimisię i potrzeb.

Wracając do “maksymalnego czasu trwania” – w Scrumie jest silna sugestia, że zespoły w miarę upływu czasu stają się coraz bardziej biegłe w tej całej zwinności. To znaczy, że większość wydarzeń nawet nie będzie miała szansy trwać tyle, ile wynosi ich timebox. Wszystkie zwykle kończą się o wiele wiele szybciej. A te sporadyczne przypadki, kiedy spędzimy nad jakimś wydarzeniem więcej czasu, to są właśnie te momenty, kiedy to więcej czasu jest nam po prostu potrzebne.

Zdarzą się trudne Planowania i trudne Retro. Będą takie Sprinty, gdzie zasadniczo nie dostarczymy żadnego Przyrostu. Po to jest timebox, żeby go wykorzystać, gdy nastanie taka potrzeba. Ale czas trwania wydarzeń Scrum nie powinien zmierzać do maksimum. Wręcz przeciwnie – sprawne zespoły działają coraz sprawniej i stałe elementy gry zajmują im coraz mniej czasu.

A co z groomingiem?!

Po pierwsze, od jakiegoś czasu nie nazywa się to grooming, ale Product Backlog Refinement. Po drugie, PBR nie jest wydarzeniem, a procesem ciągłym. To znaczy, że dzieje się w tle – na różnego rodzaju formalnych i nieformalnych spotkaniach, dyskusjach, rozmowach, itp.

“Doskonalenie Backlogu Produktu zwykle zajmuje do 10% czasu Sprintu! Razem z wydarzeniami to prawie 25%! Jedną czwartą czasu spędzimy na spotkaniach!”

No cóż, słyszeliśmy i takie głosy. Zacznijmy więc od najważniejszej rzeczy: 22% to maksymalny czas trwania wszystkiego, co zostało przewidziane w Scrum. O timeboxie dla wydarzeń już mówiliśmy. Ponieważ Refinement to proces, dla niego został podany rekomendowany maksymalny sumaryczny czas trwania – 10% Sprintu. Jeżeli mamy dobrze rozpoznany i w miarę stały backlog, to na Doskonalenie poświęcimy góra kilkadziesiąt minut na Sprint.

A jeżeli nie? Co jeśli nasze wymagania są w takim stanie, że aby zacząć pracę, musimy poświęcić dużo czasu na Refinement? To znaczy, że ta praca i tak musiałaby zostać wykonana, niezależnie od wybranej metodyki. Jeżeli wymaganie jest niejasne, trzeba je wyjaśnić – czy to pracujemy w Scrumie, czy w jakikolwiek inny sposób. Nie doliczałbym więc tych 10% do czasu trwania wydarzeń Scrum.

Podobnie zresztą sytuacja wygląda z pozostałymi elementami Scruma. Zastanówmy się, czy jesteśmy w stanie iteracyjnie wytwarzać oprogramowanie bez planowania? Czy jesteśmy w stanie stworzyć skomplikowany produkt bez regularnych spotkań z klientem i oglądaniem Przyrostu? Ile czasu zaoszczędzimy spotykając się raz dziennie na 15 minut i synchronizując nasze plany?

Bo w tych wydarzeniach chodzi właśnie o zaoszczędzony, a nie o stracony czas. Dzięki (maksymalnie) piętnastu minutom poświęconym na Daily, unikniemy sytuacji w których ktoś próbuje testować nieskończone rozwiązanie, bądź dwie osoby pracują nad tym samym, wchodząc sobie w drogę. To dzięki zgrabnemu planowaniu nie zmarnujemy dwóch tygodni Sprintu, ale dostarczymy rzeczywistą wartość.

Trzeba więc samemu sobie zadać pytanie: czy warto poświęcić trochę czasu na organizowanie naszej pracy tak, abyśmy w przewidywalny sposób sprawnie i regularnie dostarczali wartość? Bo bez tego wszystkiego możemy po prostu zacząć biegać z pustą taczką…

Czas trwania wydarzeń Scrum to ostatnio jeden z gorących tematów na naszych szkoleniach Scrum. Zapraszamy na nie zarówno zespoły stawiające swoje pierwsze scrumowe kroki, jak i doświadczone Scrum Teamy. Zakres możemy dostosować do Twoich potrzeb!