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!
Oj trzeba wrócić do ławki
„Ponieważ Refinement to proces, dla niego został podany maksymalny sumaryczny czas trwania – 10% Sprintu”
” Doskonalenie zazwyczaj zajmuje nie więcej niż
10% czasu Zespołu Deweloperskiego w Sprincie. ”
Nie ma takiego limitu, bo pierwsze Sprinty mogą wymagać i 30% czasu na ustalanie co jest do zrobienia. Proces empirytyczny pokazuje że nie mozna ograniczac czasu na doskonalenie backlogu, bo czasem trzeba wiecej na to poswiecić energii.
Gdyby był limit to by ludzie czasem nie wiedzieli co robią a Scrum Master PSM1 CMS ABS by mówił że 10% to 10%.
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Polish.pdf
„rekomendowany maksymalny sumaryczny czas trwania” 😉
Nie zgodzę się z tym, że „pierwsze Sprinty mogą wymagać i 30% czasu na ustalenie co jest do zrobienia”, bo to w 99% przypadków kończy się tym, że zespoły rozpracowują wymagania na odległe Sprinty. Niestety, w miarę postępu prac i zbliżania się do tych odległych wymagań okazuje się, te rozpoznanie i szacowanie należy wykonać ponownie. Dlatego też „Refinement usually consumes no more than 10% of the capacity” traktowałbym jako wskazówkę co do tego, ile faktycznie powinno to zająć. „Powinno”, z wyłączeniem szczególnych sytuacji, o których wspominałem w tekście.
Gratuluje profesjonalnego podejścia, nie usuniecia komentarza i poprawki tekstu. Tu już mamy subiektywne odczucia, a kto ma racje dowiemy się jak sie spotkamy w realu 😉
Pozdrawiam!
Trudno byłoby pisać o transparentności i zamiatać cokolwiek pod dywan. Tym bardziej, że nikt nie ucieka od stwierdzenia „maksymalny rekomendowany czas na refinement” – tak o tym mówimy na naszych szkoleniach i taka jest rekomendacja #białko. Zawsze powtarzamy, że nie jesteśmy ewangelizatorami Scruma, a Scrum Guide to nie biblia. Jest dużo miejsca na interpretacje i praktyczne rekomendacje. Z naszej praktyki wychodzi, że w 90+% przypadków 10% czasu to aż nadto.
Pracuję w scrumie jako programista i mam co raz bardziej dosyć.
Jeden dzień na demo i retrospekcję. Drugi dzień na planowanie. Trzeci dzień na grooming. Sprint ma 10 dni roboczych bo weekendów nie liczę. 3/10 wynosi 30%!
W teorii na groomingach mamy się wymieniać ale w praktyce chodzą ci sami ludzie albo nie ma się z kim wymienić.
Nie mówię juz o tym że mamy też inne spotkania w ciągu tygodnia. I że już 3 dni przed końcem sprintu zaczyna się wypytywanie ludzi czy zdążą skończyć taski. Czy wszystko jest ok ? Chyba nie
Niestety, jest powszechny problem z błędnym stosowaniem całkiem niezłej metodyki, jaką jest Scrum. Jeżeli są dwutygodniowe Sprinty to Review+Retro (nie ma czegoś takiego jak „demo”) to góra 3,5 godziny, a często mniej. Planowanie to maksymalnie 4 godziny, a często o wiele krócej – https://www.youtube.com/watch?v=SRZMd-9kGzM Jeśli „grooming” nie jest efektywny ani przydatny, to trzeba zmienić jego formułę. Moje pytanie brzmi, co na to Scrum Masterzy? Czy wiedzą, że zespoły mają takie problemy? Czy te kwestie poruszane są na retro?
Zastanawia mnie kiedy dokładnie organizować spotkania które mają mieć miejsce między zakończeniem obecnego sprintu a rozpoczęciem nowego (planning, review, retrospective), przy założeniu, że między sprintami nie ma żadnego odstępu – jeden się kończy i zaczyna się koleny. Jak to u Was wygląda?
Sprint kończy się z ostatnią sekundą Retrospektywy. Kolejna sekunda to pierwsza sekunda Planowania nowego Sprintu. Najczęściej te dwie sekundy dzieli więcej czasu, bo często ostatnia sekunda Sprintu to 16:59:59 w piątek, a Planowanie rozpocznie się o 09:00:00 w poniedziałek. 🙂