W połowie maja 2025 udostępniłem test z wiedzy o Scrumie składający się z pięciu pytań. W ciągu pierwszego miesiąca wzięło w nim udział nieco ponad 100 osób, więc mogę pokusić się o podsumowanie. I przy okazji wyjaśnić, dlaczego takie, a nie inne odpowiedzi są prawidłowe.

Jeśli ktoś ma ochotę spróbować swych sił, test jest nadal dostępny – wystarczy skorzystać z tego linku i odpowiedzieć na pytania przed przejściem do lektury dalszej części artykułu.

Podstawowe statystyki

Test został wykonany ponad 100 razy, choć niewykluczone, że niektóre osoby podeszły do niego dwukrotnie.

Średni wynik testu to 2 punkty na 5 możliwych. A więc jest bardzo niski…

Do tego tylko dwie osoby (mniej niż 2% respondentów) udzieliły poprawnych odpowiedzi na wszystkie pytania, a cztery kolejne (czyli nieco ponad 3%) zdobyły 4 punkty na 5.

Na szczęście respondentów, którzy nie uzyskali żadnego punktu, też było niewielu (4 osoby, a więc również nieco ponad 3% respondentów).

Wyniki nie napawają optymizmem, ale niezbyt mnie zaskoczyły. Scrum jest prosty, ale niekoniecznie trywialny i mam wrażenie, że wielu użytkowników tej metody nie do końca rozumie jej wszystkie aspekty. Wszak wszystkie nieporozumienia i mity, którym poświęciłem cały cykl artykułów (oto link do pierwszego z nich), nie wzięły się z niczego.

A teraz pora przejść do poszczególnych pytań i omówić je wraz z odpowiedziami.

Problem 1: trzy Zespoły Scrum, jeden produkt

Pytanie pierwsze dotyczy tego, ile powinno być Backlogów Produktu, Backlogów Sprintu oraz Product Ownerów w sytuacji, gdy trzy Zespoły Scrum rozwijają jeden produkt.

Prawidłowych odpowiedzi udzieliło 54% respondentów.

Trzy Zespoły Scrum pracują nad jednym produktem. Które z poniższych stwierdzeń są prawdziwe, jeżeli Zespoły te prawidłowo posługują się Scrumem?

Odpowiedzi wraz z odsetkiem respondentów, którzy je zaznaczyli:

  1. Istnieje jeden Backlog Produktu, wspólny dla wszystkich Zespołów (94.05%)
  2. Istnieją trzy Backlogi Produktu, po jednym dla każdego z Zespołów (1.19%)
  3. Istnieje jeden Backlog Sprintu, wspólny dla wszystkich Zespołów (5.95%)
  4. Istnieją trzy Backlogi Sprintu, po jednym dla każdego z Zespołów (78.57%)
  5. Jest trzech Product Ownerów, po jednym w każdym Zespole (5.95%)
  6. Jest jeden Product Owner nienależący do żadnego Zespołu (16.67%)
  7. Jest jeden Product Owner należący do wszystkich trzech Zespołów (77.38%)

Aby odpowiedzieć na to pytanie, wystarczy przeczytać z uwagą Scrum Guide, więc nie dziwi mnie, że najwięcej osób wskazało odpowiedź pierwszą, czwartą oraz siódmą, bo właśnie te trzy są poprawne.

Procenty nie sumują się do okrągłej liczby 100, bo pytanie pozwalało na wybranie więcej niż jednej odpowiedzi.

Ile powinno być Backlogów Produktu?

Jeśli produkt jest jeden, niezależnie od tego, jak wiele Zespołów Scrum zajmuje się jego równoczesnym rozwojem, Backlog Produktu wciąż pozostaje jeden. Dzięki temu interesariusze i wszystkie Zespoły dysponują jednym źródłem informacji o planowanych zmianach w produkcie i kolejności ich realizacji, jakiej oczekuje Product Owner.

Gdyby każdy Zespół Scrum dysponował osobnym Backlogiem Produktu, na pierwszy rzut oka może mieć to sens, bo można zadbać o to, by elementy się nie duplikowały pomiędzy nimi. Jak jednak w takiej sytuacji określić kolejność realizacji tych elementów i w ogóle świadomie nią zarządzać?

Nie wystarczyłoby popatrzyć, w jakiej są umieszczone na liście, bo list tych byłoby kilka. Konieczne stałoby się dodanie informacji umożliwiających zrozumienie, jak mają się one do elementów wszystkich pozostałych Backlogów Produktu. Aby zrozumieć, dokąd zmierza development całego produktu, należałoby analizować wszystkie listy, więc nie pojawia się żadna korzyść z wprowadzenia wielu Backlogów, za to zarządzanie nimi staje się trudniejsze i dramatycznie spada przejrzystość.

A to nie wszystko, bo istnienie więcej niż jednego Backlogu Produktu dawałoby możliwość ustanawiania różnych Celów Produktu w każdym z nich. To już przepis na utratę skupienia, czego skutkiem będzie powolne pełzanie rozwoju produktu w różnych kierunkach (przyjmując litościwie, że Cele te nie będą rozbieżne), zamiast szybkie osiąganie bieżącego Celu i przejście do pracy nad kolejnym, który zostanie wtedy ustanowiony.

Czy Backlog Sprintu powinien być wspólny?

Jeśli nad developmentem produktu pracują trzy Zespoły Scrum, każdy z nich działa w niezależnych Sprintach. Inaczej mówiąc, mimo że produkt jest jeden, równolegle odbywa się tyle Sprintów, ile różnych Zespołów pracuje nad jego rozwojem. A skoro Sprinty są rozdzielne, takie też muszą być Backlogi Sprintów, bo artefakt ten tworzony jest przez Developerów w każdym z Zespołów Scrum w trakcie Planowania Sprintu.

Co więcej, każdy z Zespołów ustali na potrzeby swego Sprintu różny Cel, do którego osiągnięcia będzie dążył, bo przecież pracować będą one nad różnymi zmianami w produkcie (gdyby wszyscy pracowali nad tym samym, jaki sens miałby dzielenie się na osobne Zespoły?). Próba posłużenia się jednym Backlogiem Sprintu spowodowałaby też, że wszyscy Developerzy z trzech Zespołów musieliby wspólnie przeprowadzać Daily Scrumy.

Ilu potrzeba Product Ownerów?

Odpowiedź jest dość oczywista: produkt ma zawsze tylko jednego Product Ownera, który ustala jeden Cel Produktu i zarządza wynikającym z tego Celu Backlogiem Produktu.

Gdyby Product Ownerów było kilku, interesariusze nie mieliby jasności, kto podejmuje decyzje odnośnie do tego, co w produkcie zostanie zrealizowane, a co zostanie pominięte jako zmiana zbędna lub mało wartościowa.

Co więcej, skoro Backlog Produktu musi być jeden, próba zarządzania tym artefaktem przez trzech różnych Product Ownerów prowadziłaby do nieporozumień, rozbieżnych decyzji, a niewykluczone, że niepotrzebnych dyskusji spowalniających cały proces.

Product Owner jest więc jeden i jest członkiem wszystkich Zespołów Scrum, które rozwijają jego produkt – niezależnie od ich liczby. Tak, nie jest to proste, ale da się zrobić, póki produkt nie przekroczy możliwości kognitywnych i czasowych jednej osoby. A gdyby do tego doszło, nie powinno się „skalować Product Ownera”, ale zamiast tego dokonać sensownej dekompozycji produktu np. na dwie niezależnie rozwijane części. Pisałem zresztą o tym całkiem niedawno w tym artykule.

Problem 2: jeden Sprint, dwa produkty

Drugie pytanie związane jest z liczbą produktów, nad którymi w trakcie jednego Sprintu może pracować jeden Zespół Scrum.

Tylko 19% uczestników testu wskazało prawidłową odpowiedź.

Czy w trakcie Sprintu Zespół Scrum może pracować nad rozwojem dwóch różnych produktów?

Odpowiedzi wraz z odsetkiem respondentów, którzy je zaznaczyli:

  1. Tak, bez dodatkowych warunków (23.81%)
  2. Tak, pod warunkiem, że produkty te mają tego samego Product Ownera i interesariuszy (2.38%)
  3. Tak, pod warunkiem, że są to produkty zależne od siebie lub stanowią część jednego portfolio produktów (4.76%)
  4. Tak, pod warunkiem, że produkty te mają taką samą Definicję Ukończenia (2.38%)
  5. Tak, pod warunkiem, że nie ma wystarczającej ilości pracy nad jednym produktem, by wypełnić nią cały Sprint (5.95%)
  6. Tak, pod warunkiem, że ustanowiony zostanie jeden Cel Sprintu wspólny dla obu produktów (33.34%)
  7. Tak, pod warunkiem, że Cel Sprintu i większość wykonywanej pracy związane będą tylko z jednym z tych produktów (4.76%)
  8. Nie, ponieważ to wymagałoby ustanowienia dwóch różnych Celów Sprintu (19.05%)
  9. Nie, ponieważ zabraniają tego zapisy Scrum Guide (3.57%)

Najwięcej osób wybrało odpowiedź szóstą, a nieco mniej, ale wciąż dużo, odpowiedź pierwszą – obie są błędne, bo prawidłowa jest tylko odpowiedź ósma.

Czy zabrania tego Scrum Guide?

Nie, nie ma definicji metody stosownego zakazu ani nawet wskazówki, czy taki sposób pracy Zespołu Scrum jest dopuszczalny. Scrum Guide nie jest bowiem instrukcją stosowania Scruma, ale zbiorem zasad, wedle których należy konstruować proces i dobierać do niego niezbędne praktyki oraz inne narzędzia.

Stąd też wybór właściwej odpowiedzi wymaga połączenia w logiczną całość różnych zapisów, a więc wyciągnięcia z nich wniosków. Aby pracować nad rozwojem więcej niż jednego produktu w jednym Sprincie, Zespół musiałby zaplanować go na podstawie dwóch różnych Backlogów Produktu, kierując się przy tym dwoma różnymi Celami Produktu.

Czy nie wystarczy, żeby Cel Sprintu był jeden?

Da się bez większego trudu ustalić Cel Sprintu taki, by obejmował dowolną liczbę produktów, jeśli Zespół bardzo się przy tym uprze. Jeden Cel Sprintu to jednak w Scrumie warunek konieczny, ale niewystarczający do sensownego zaplanowania iteracji.

Sprint powinien bowiem służyć nie tylko wykreowaniu jakiejś wartości dla interesariuszy, ale też przybliżeniu się do osiągnięcia Celu Produktu, z jakiego wynika Backlog Produktu, na podstawie którego Sprint ten został zaplanowany.

I tu pojawia się problem: jeśli produktów jest wiele, każdy z nich będzie miał osobny Cel Produktu i plan jego osiągnięcia (czyli Backlog Produktu). To oznacza, że jest niemal niewykonalne określenie takiego Celu Sprintu, który naprawdę (a nie na siłę) wynikałby z obu różnych Celów Produktu i był jednocześnie sensowny, mierzalny oraz by pomagał Developerom w podejmowaniu decyzji w trakcie iteracji.

A jeśli Cele Sprintu byłyby dwa, to w praktyce oznaczałoby podzielenie się Zespołu (niejawne) na dwie części, z których każda zajmuje się właściwie czym innym, zupełnie tak, jakby pracowali w równoległych iteracjach. Co więcej, w takim układzie nieuchronnie pojawiłaby się konieczność wyboru, który z tych Celów jest ważniejszy za każdym razem, gdy Developerzy podejmowaliby decyzję, czym należy zająć się najpierw…

A jeśli Definicja Ukończenia jest wspólna?

To nic nie zmienia, bo określa ona oczekiwany poziom jakości strukturalnej, czyli to, jak produkt ma być budowany, a nie jaki produkt ma powstać. Inaczej mówiąc, podobieństwo Definicji Ukończenia różnych produktów nie powoduje, że można nimi zarządzać tak, jakby były one jednym produktem. Nie są, bo z każdym z nich związane są inne potrzeby, mają innych interesariuszy, inne Cele Produktu i osobne Backlogi Produktu.

Poza tym nawet taka sama Definicja Ukończenia nie wyeliminuje problemu z ustaleniem sensownego Celu Sprintu, o którym piszę powyżej.

Ten sam Product Owner nie wystarczy?

Nie, ponieważ nadal będą istnieć dwa różne produkty, różne Cele Produktu i oddzielne Backlogi Produktu. Oczywiście na siłę można poupychać elementy na jednej liście, ustalić jakiś generyczny Cel Produktu, który będzie pozorował, że wszystko odbywa się zgodnie z zasadami i można zacząć robić pseudo-Sprinty…

Ze Scrumem nie będzie to jednak miało wiele wspólnego, bo brak w tym skupienia i przejrzystości, a Sprint zaczyna się redukować do funkcji kontenera na wykonanie prac zlecanych Developerom przez Product Ownera, zamiast służyć do empirycznego rozwoju konkretnego produktu.

Co robić, gdy pracy w jednym produkcie jest za mało, a drugi czeka?

Wątpię, by ktokolwiek często stał przed problemem, że w jakimś produkcie jest za mało do zrobienia. A jeśli nawet, powinien zastanowić się, czy aby nie nastąpił moment, w którym dalszy rozwój produktu powinien się zakończyć.

Powiedzmy jednak, że ci sami ludzie muszą dbać o rozwój dwóch różnych produktów. Czy da się to zrobić zgodnie z zasadami Scruma? Oczywiście.

Jedno rozwiązanie: zacząć realizować krótkie Sprinty, po czym poświęcać każdy z nich temu produktowi, w którym akurat jest pilniejsza praca (albo wystarczająco pracy) do zrobienia.

Drugie rozwiązanie: Zespół może podzielić się na dwie mniejsze części, z których każda od tego momentu zajmie się jednym produktem. Zamiast wprowadzania zamieszania, będzie pełna przejrzystość odnośnie do tego, kto i czym się zajmuje i na jakim Celu Produktu (a w konsekwencji i Celu Sprintu) ma się skupić.

Nigdy nie wolno pracować w Sprincie nad dwoma produktami?

Bywa tak, że z różnych względów Developerzy muszą wykonać w trakcie Sprintu pracę nad więcej niż jednym produktem. Może to wynikać z odpowiedzialności za coś, co wcześniej wytworzyli i czym nadal się opiekują, reagując na zgłoszone problemy lub awarie. Scrum nie zabrania czegoś takiego, bo zabronić nie może – metoda jest do bólu pragmatyczna.

Rzecz w tym, że charakter tych dodatkowych prac jest różny – nie jest to rozwój produktu. Developerzy, planując Sprint, który skupiony jest na jednym produkcie, muszą wtedy zarezerwować sobie czas (w takiej czy innej formie), by móc wywiązać się ze wszelkich stałych zobowiązań, jakie na nich w danej organizacji spoczywają.

Jak to zrobić w praktyce? Developerzy mogą ustalić, że wszelkie prace niezwiązane z bieżącym Sprintem (i produktem, jaki jest w nim rozwijany) wykonywane są zawsze w ostatniej godzinie dnia roboczego (a może w pierwszej lub dowolnej innej). Albo, że Zespół zajmuje się nimi po lunchu we wtorki i czwartki. Może też zostać wyznaczony do ich wykonania dyżurny Developer, który nie bierze wtedy udziału w Sprincie.

Natomiast jeśli te dodatkowe prace miałyby służyć również rozwojowi jakiegoś produktu, choćby w niewielkim zakresie, to jednak – o ile chcemy prawidłowo posługiwać się Scrumem – wciąż powinno się to odbywać w niezależnie zaplanowanych i odbywających się równolegle Sprintach, a nie w ramach jednej iteracji. Tak dla dobra Zespołu, jak i dla obu produktów i ich interesariuszy.

Problem 3: użycie nieukończonego produktu

Kolejne pytanie dotyczy prawa Product Ownera do udostępnienia użytkownikom produktu, nad którym prace nie zostały w pełni ukończone.

42% respondentów wskazało prawidłową odpowiedź.

Czy Product Owner może zdecydować o przekazaniu do użytkowania najnowszej wersji produktu, mimo że Developerzy poinformowali go, iż nie spełnia ona wymogów Definicji Ukończenia?

Odpowiedzi wraz z odsetkiem respondentów, którzy je zaznaczyli:

  1. Tak, bo to jego produkt (23.81%)
  2. Tak, o ile Developerzy zgodzą się na to (1.19%)
  3. Tak, o ile Scrum Master zgodzi się na to (0.00%)
  4. Tak, o ile cały Zespół Scrum zgodzi się na to (11.90%)
  5. Tak, o ile interesariusze Zespołu zgodzą się na to (14.29%)
  6. Nie, bo użyty może być wyłącznie Przyrost, a najnowsza wersja produktu nim nie jest (41.67%)
  7. Nie, bo zakazują tego zapisy Scrum Guide (7.14%)

Wielu respondentów decydowało się na zaznaczenie błędnej odpowiedzi pierwszej, czwartej lub piątej, zamiast tej poprawnej, czyli szóstej.

Product Owner nie może wszystkiego?

Wydaje się, że właściciel czegoś może dysponować tym czymś w dowolny sposób, stąd podpowiedź intuicji, że Product Owner ma prawo przekazać do użycia produkt niezależnie od tego, w jakim ten produkt jest stanie. I technicznie pewnie tak jest w wielu organizacjach, ale w Scrumie sensu nie ma to żadnego.

Skoro bowiem Zespół ustala, co to znaczy, że produkt został wytworzony w sposób zapewniający mu wymaganą jakość strukturalną (czyli jest dobrze zrobiony od strony technicznej), jaki sens jest w użyciu czegoś, co takich kryteriów nie spełnia?

Zbiorem tych kryteriów jest oczywiście Definicja Ukończenia, a brak pewności, czy zawarte w niej warunki zostały zaspokojone, oznacza, iż developement wciąż trwa. Nie da się bezpiecznie i z korzyściami dla kogokolwiek użyć produktu, który nadal jest wytwarzany i prace nad nim nie zostały ukończone.

Co nadaje się do użycia?

W dobrze działającym Scrumie użyty może być każdy Przyrost, a więc nowa wersja produktu, która spełnia warunki ujęte w Definicji Ukończenia. Jeśli nie powstał nowy Przyrost (albo prościej: jeśli nowa wersja produktu jeszcze nie powstała lub nie spełnia warunków jakościowych), brak jest podmiotu decyzji czy to Product Ownera, czy całego Zespołu, czy kogokolwiek innego, odnośnie do użycia czegoś takiego.

Dopiero gdy prace zakończą się i Developerzy potwierdzą ten fakt, można rozważać, czy najnowszy powstały w ten sposób Przyrost powinien być użyty, czy też nie. I wciąż nie będzie to samodzielna decyzja Product Ownera, bo czasami skutki użycia wczesnej wersji jakiegoś rozwiązania (w pełni ukończonego technicznie, ale niekompletnego funkcjonalnie) mogą dramatycznie utrudnić dalszy development. Dlatego decyzję tę powinien podjąć cały Zespół.

Czemu Scrum Guide jasno tego nie określa?

Bo nie musi, dlatego że wynika to z innych zapisów. Sprinty służą wytwarzaniu rozwiązań nadających się do użycia i w pełni ukończonych, a kryterium oceny jest tu Definicja Ukończenia. Jeśli prace nad czymś nadal trwają, można dyskutować jedynie o tym, czy i w jaki sposób będą one dokończone, a nie o przekazaniu tego czegoś do użycia.

Problem 4: cechy Przyrostu w Scrumie

Przedostatnie pytanie wymaga wskazania cech, jakie ma Przyrost.

Dramatycznie mało osób zaznaczyło wszystkie prawidłowe odpowiedzi – zaledwie 4% respondentów.

Które z poniższych stwierdzeń poprawnie opisują, czym jest Przyrost w Scrumie?

Odpowiedzi wraz z odsetkiem respondentów, którzy je zaznaczyli:

  1. Najnowszy Przyrost zawiera w sobie wszystkie poprzednie Przyrosty (44.05%)
  2. Przyrost to inaczej zbiór wszystkich zmian, jakich Developerzy dokonali w produkcie w trakcie Sprintu (54.76%)
  3. Zespół Scrum powinien wytworzyć w Sprincie dokładnie jeden Przyrost (13.09%)
  4. Przyrost, po tym, gdy powstanie, jest już niezmienny (11.90%)
  5. Zespół Scrum powinien wytworzyć w Sprincie przynajmniej jeden Przyrost (59.52%)
  6. W tym samym momencie może powstać dowolna liczba Przyrostów tego samego produktu, jeśli nad jego rozwojem pracuje równolegle kilka Zespołów Scrum (60.71%)
  7. Przyrost powstaje dopiero w momencie, gdy Zespół Scrum osiągnie Cel Sprintu (9.52%)
  8. Przyrost może powstać w wyniku usunięcia z produktu części istniejącej w nim funkcjonalności (59.52%)

Poprawne odpowiedzi wybierane były często, ale większość uczestników testu pomijała niektóre z nich. A należało wskazać odpowiedzi pierwszą, czwartą, piątą oraz ósmą.

Oczywiście procenty znów nie sumują się do 100, bo pytanie pozwalało na wskazanie więcej niż jednej odpowiedzi.

Przyrost to nie zbiór zmian produktu dokonanych w Sprincie?

Taka odpowiedź jest do pewnego stopnia poprawna, ale niejednoznaczna i niekompletna. Tak, każdy Przyrost zawiera w sobie wszystkie zmiany, jakie Developerzy zrealizowali w produkcie do momentu jego powstania. Co oznacza, że zawiera wszystkie poprzednie Przyrosty w sobie.

Inaczej mówiąc, Przyrostem nie jest tylko to, co zmieniło się w bieżącym Sprincie, ale cała nowa wersja produktu, spełniająca kryteria zawarte w Definicji Ukończenia. Czyli zarówno to, co się zmieniło, jak i to, co nie miało się zmienić i wciąż działa tak, jak wcześniej.

Ile Przyrostów powstaje w Sprincie?

Przyrostów w trakcie Sprintu może powstać wiele, z których każdy jest rozwinięciem tego, który powstał przed nim. Notabene to oznacza, że będą też Przyrosty, które powstaną na długo przed końcem Sprintu, a więc niektóre z nich nie będą obejmować wszystkich zmian dokonanych w trakcie iteracji (bo ta wciąż trwa).

Poza tym, gdyby trzymać się definicji, w myśl której Przyrost musi obejmować wszystkie zmiany zrealizowane w Sprincie, to w każdej iteracji musiałby powstawać dokładnie jeden Przyrost na sam koniec. A przecież nie ma takiego wymogu w Scrum Guide i byłoby to sprzeczne z ideą inkrementalnego rozwoju produktu.

Dwa lub więcej Przyrostów powstających naraz?

Przyrostów może powstać wiele, ale nigdy w tym samym momencie. Wystarczy zastanowić się nad konsekwencjami, gdyby tak się stało. Każdy taki „Przyrost” byłby nieco inny, bo zawierałby różne zmiany, których dokonali w produkcie Developerzy. Oczywiście każdy z nich mógłby spełniać samodzielnie wymogi Definicji Ukończenia, niemniej nie wolno zapominać, że produkt jest jeden.

A to oznacza, że jego użytkownicy chcą otrzymać jeden produkt, w którym działają wszystkie zrealizowane funkcjonalności, a nie dwa różne rozwiązania, z których każde dostarcza jedynie część oczekiwanych cech i funkcjonalności.

Dlatego, jeśli powstają dwie nowe wersje produktu (albo więcej) w tym samym czasie, żadna z nich nie jest Przyrostem, dopóki nie zostaną one złączone w jedną całość i Developerzy nie potwierdzą, że ta całość wytworzona została w myśl Definicji Ukończenia. Dobrze przy tym byłoby, ale taki wymóg był częścią tej Definicji.

Kiedy Przyrost się zmienia?

Cóż, nigdy. Każda zmiana w powstałym już Przyroście oznacza, że rozpoczął się dalszy development produktu, a ukończenie takich prac skutkuje powstaniem kolejnego Przyrostu.

Można powiedzieć, że produkt zmienia się cały czas w ramach jego rozwoju, natomiast kolejne Przyrosty są niezmienne od momentu ich powstania.

Jak ma się Przyrost do Celu Sprintu?

Aby osiągnąć ustalony Cel Sprintu, Developerzy muszą dokonać takich zmian w produkcie, które pozwolą ten Cel osiągnąć. Czyli muszą wytworzyć coś, co nada produktowi nowe cechy lub funkcjonalności, zmieni te istniejące wcześniej, albo – co niewykluczone – usuną coś zbędnego z produktu.

Oznacza to, że aby osiągnąć Cel Sprintu, konieczne jest wytworzenie przynajmniej jednego Przyrostu w Sprincie, bo bez tego nie można stwierdzić, że jakiekolwiek prace zostały ukończone.

Natomiast samo wytworzenie Przyrostu nie implikuje osiągnięcia Celu Sprintu. Przyrost to po prostu nowa wersja produktu, który spełnia wymogi Definicji Ukończenia. Być może do osiągnięcia Celu Sprintu konieczne będzie zrealizowanie np. 20 zmian w produkcie, a Developerzy będą nad nimi pracować sekwencyjnie. Po zakończeniu prac nad każdą z nich powstanie nowy Przyrost, ale dopiero ten dwudziesty z kolei umożliwi osiągnięcie Celu Sprintu.

Poza tym zdarza się, że powstanie nowa wersja produktu i jest ona Przyrostem, a mimo to Celu Sprintu nie udaje się osiągnąć, bo nie wszystko, co było do tego niezbędne, zostało zrealizowane. Lub też Cel okazał się nieosiągalny z przyczyn niezależnych od Zespołu.

Problem 5: długość Sprintu liczona dniami roboczymi

Ostatnie pytanie z testu dotyczy sposobu ustalania długości Sprintu.

Było najprostsze, więc prawidłową odpowiedź wybrało aż 85% respondentów.

Zespół Scrum zdecydował, że będzie pracował w Sprintach, których czas trwania to kolejnych dziesięć dni roboczych. Czy taki sposób ustalenia długości Sprintu jest w Scrumie prawidłowy?

Odpowiedzi wraz z odsetkiem respondentów, którzy je zaznaczyli:

  1. Nie, bo dni rozpoczynania i zakończenia Sprintów będą za każdym razem wypadać w różne dni tygodnia (3.57%)
  2. Nie, bo długość Sprintów nie będzie wielokrotnością tygodnia (0.00%)
  3. Nie, bo faktyczny czas trwania poszczególnych Sprintów będzie różny, zależnie od liczby dni świątecznych wypadających w ich trakcie (7.14%)
  4. Tak, bo Sprinty będą mieć stałą długość krótszą niż jeden miesiąc i liczoną dniami roboczymi (84.53%)
  5. Nie, bo Sprinty zaczynać powinny się w poniedziałki i kończyć w piątki (0.00%)
  6. Nie, bo konieczne będzie zaplanowanie kalendarium zdarzeń Scrum z dużym wyprzedzeniem, a to sprzeczne z podejściem zwinnym (4.76%)

Prawie wszyscy wybrali jedyną prawidłową odpowiedź czwartą, aczkolwiek pojedyncze osoby zdecydowały się na wskazanie błędnych odpowiedzi pierwszej, trzeciej lub szóstej.

Dni zaczynania i kończenia Sprintów mogą być zmienne?

Nie ma w Scrumie wymogu, by iteracje zaczynać i kończyć zawsze w te same dni tygodnia. Do pewnego stopnia ułatwia to organizację zdarzeń scrumowych, więc zwykle tak się dzieje, ale nie musi.

Jedyne, czego wymaga metoda, to by Sprinty miały z góry określony czas trwania, nie dłuższy niż miesiąc (nawet bez wskazania, czy chodzi o miesiąc kalendarzowy, czy np. o cztery tygodnie).

Jest też w definicji Scruma rekomendacja, by Sprinty miały tę samą długość, aby uniknąć ciągłego żonglowania nią, dzięki czemu proces uzyska stały rytm. Odradzam ignorowanie tej rekomendacji, niemniej nie jest ona twardym wymogiem i na upartego można tak robić.

Czy długość Sprintów liczona dniami roboczymi nie będzie zmienna?

Nie, wręcz przeciwnie. Jeśli Zespół trzyma się konsekwentnie zasady, że Sprint trwa przez określoną liczbę dni roboczych, każdy z nich będzie trwał dokładnie tyle samo – faktycznie, ale nie kalendarzowo.

Co więcej, rozwiązanie to eliminuje problemy z wszelkiego rodzaju długimi weekendami czy świętami, które powodują, że Sprinty odbywające się wedle stałej kadencji kalendarzowej, bywają krótsze lub dłuższe, jeśli chodzi o faktyczną liczbę dni roboczych, jakie obejmują.

Natomiast niekoniecznie jest to wygodne rozwiązanie, ponieważ ciągłe zmiany dni, kiedy odbywa się Planowanie Sprintu albo Przegląd Sprintu, mogą utrudnić organizację tych zdarzeń. Przykładowo, interesariusze mogą mieć problem z dostępnością, by uczestniczyć w każdym Przeglądzie Sprintu.

A nie powinny to być wielokrotności tygodni?

Wiele Zespołów organizuje Sprinty tak, by zaczynały się one w poniedziałki i kończyły w piątki. Nieco mniej decyduje się na wybór dni rozpoczęcia i zakończenia iteracji w środku tygodnia, ale wciąż trzyma się idei, że czas ich trwania to wielokrotności tygodni. To upraszcza kwestie organizacyjne.

Niemniej Scrum tego nie wymaga, nie ma też nawet zalecenia, by tak robić. Dowolna długość Sprintu, o ile nie jest on dłuższy niż jeden miesiąc, jest dopuszczalna – jeśli Zespół dostrzeże w tym sens, może robić iteracje np. czterogodzinne i też będą one zgodne z zasadami. Przykładowo, takie właśnie krótkie Sprinty stanowią jeden z elementów szkolenia Applying Professional Scrum for Software Development.

Ten test nie jest podchwytliwy

Niewątpliwie pytania nie były trywialne, a wiele niepoprawnych odpowiedzi ująłem w kuszącej formie, żeby odwoływały się do mitów o Scrumie, nieporozumień i uproszczeń, z jakimi sam się zetknąłem. Niemniej nie starałem się zastawiać pułapek na respondentów.

Zdecydowanie nie ułatwiło wyboru właściwych odpowiedzi to, że nie wskazałem, ile z nich jest poprawnych tam, gdzie należało wybrać więcej niż jedną. Zważywszy na to, że test dotyczy mimo wszystko dość podstawowych kwestii związanych ze Scrumem, uznałem to za niepotrzebne ułatwienie.

Pojawiło się też pytanie, czy poziom trudności testu jest taki sam, jak egzaminu Professional Scrum Master poziom I. W zasadzie tak, bo potencjalnie sama lektura Scrum Guide ze zrozumieniem powinna wystarczyć, by dobrze odpowiedzieć na wszystkie pytania. Jedyna różnica tkwi we wspomnianym braku wskazówek, ile odpowiedzi należy wybrać – w trakcie egzaminu PSM I prawie zawsze się one pojawiają (brak ich tylko wtedy, gdy pytanie jest naprawdę podstawowe albo wszystkie odpowiedzi są poprawne).

Na wszelki wypadek przypominam też, że test dotyczy Scruma, a nie inspirowanych nim metod skalowania Agile, gdzie pojawiają się pomysły takie, jak wielu Product Ownerów, hierarcha Backlogów Produktu i inne plastry na urwaną nogę, które dają złudzenia, że da się efektywnie rozwijać produkt ogromny, niemożliwy do pełnego objęcia umysłem jednej osoby.

Więcej testów i wiedzy

Niedługo udostępnię kolejny krótki test z wiedzy o Scrumie, więc będzie kolejna okazja, by się sprawdzić. Wciąż też można zmierzyć się z testem dotyczącym miar kanbanowych, którego omówienie opublikuję wkrótce. A zainteresowanych dobrym zrozumieniem Scruma i przygotowaniem do egzaminu PSM I zapraszam na szkolenie Professional Scrum Master.

Professional Scrum Master

Poznaj Scrum, dowiedz się, co robi Scrum Master.
Zajęcia online 19-22 sierpnia 2025, 4 godziny dziennie po polsku. Cena 3000 zł. Kliknij, by poznać szczegóły i korzyści.