Blog

Ukazała się już uaktualniona wersja Scrum Guide – dokumentu, który stanowi definicję najpopularniejszej metody zwinnej, jaką jest Scrum. Jakie zmiany przynosi?

Szczegółowe omówienie możecie obejrzeć też na nagraniu z webinaru z 19 listopada 2020.

Scrum Guide 2020 z komentarzemPobierz najnowszy Scrum Guide w formie e-booka z obszernym komentarzem Andy’ego Brandta i Rafała Markowicza.

Na początek warto podkreślić, że Scrum się nie zmienił: to wciąż framework (czyli ramy postępowania) oparty o empiryczną kontrolę procesu, umożliwiający rozwiązywanie złożonych problemów w zmiennym i nieprzewidywalnym środowisku.

Natomiast sam dokument oczywiście się zmienił. Jest zdecydowanie krótszy od poprzednich i zmieniła się jego struktura. Głównym celem, jaki przyświecał autorom – Kenowi Schwaberowi i Jeffowi Sutherlandowi – było dalsze uproszczenie Scrum Guide, usunięcie rzeczy, które są w istocie opisami praktyk (czyli mogą w Scrumie być realizowane na różne sposoby) oraz poprawienie sformułowań tak, by uniknąć nieporozumień.

Co się zatem zmieniło? W telegraficznym skrócie lista kluczowych zmian wygląda następująco:

• Role zastąpione zostały odpowiedzialnościami (ang. accountability) konkretnych osób w Zespole Scrum: Product Ownera, Developerów oraz Scrum Mastera.
• Usunięte zostało pojęcie Zespołu Developerskiego, aby podkreślić, że cały Zespół Scrum ma za zadanie skutecznie dostarczać wartość interesariuszom.
• Jednoznacznie wskazana została odpowiedzialność Scrum Mastera za skuteczność (ang. effectiviness) całego Zespołu Scrum.
• Każdy z artefaktów zaopatrzony został w zobowiązanie (ang. commitment), które ma zapewnić skupienie Zespołu Scrum i przejrzystość samego artefaktu:
  • Cel Produktu związany jest z Backlogiem Produktu,
  • Cel Sprintu związany jest z Backlogiem Sprintu,
  • Definicja Ukończenia związana jest z Przyrostem.
• Z opisu elementów Scruma usunięte zostały sugerowane sposoby realizacji zdarzeń i pracy z artefaktami oraz praktyk, jakich należy do tego używać.
• Usunięte zostały odwołania do praktyk związanych z wytwarzaniem oprogramowania, aby ułatwić użycie Scruma w innych dziedzinach.

W naszej ocenie najnowszy Scrum Guide nie przynosi fundamentalnej zmiany w metodzie i daje Zespołom jeszcze większą swobodę w elastycznym jej użyciu niż do tej pory. Mimo to mamy nadzieję się, że w wielu organizacjach i Zespołach wywoła spore Zamieszanie, które przyczyni się do poprawy jakości stosowania w nich Scruma. Odpowiedzialność za efekty i wartość pracy Zespołu została w Scrum Guide 2020 zdefiniowana w sposób, którego nie da się pogodzić z marnymi praktykami i „Scrumem-zombie”. Również traktowanie Product Ownera lub Scrum Mastera jako stanowiska pracy opisanego zestawem wykonywanych czynności nie pasuje do nowego Scrum Guide, bo już nie ma w nim ról.

Jeden Zespół

Idea Zespołu Developerskiego – zbiorowej roli w Zespole Scrum – sprawiała wiele kłopotów i nieporozumień. Nie zawsze było wiadomo, o którym Zespole mowa, poza tym w praktyce dla większości użytkowników Scruma praktycznie bez znaczenia był Zespół Scrum, traktowany jako coś formalnego, o czym warto pamiętać jedynie podczas egzaminów certyfikacyjnych.

Dużo większym problemem jest to, że istnienie Zespołu w Zespole prowokowało do omawiania ról w Scrumie w taki sposób, jakby Product Owner funkcjonował obok prac odbywających się w Sprincie, a Scrum Master lewitował radośnie gdzieś w oddali. Zbudowało się i utrwaliło patrzenie na Sprinty i wytwarzanie wartości w nich jak na coś, co dotyczy wyłącznie Developerów.

Tymczasem Zespół Scrum jako całość ma konkretny cel: rozwiązywać złożone problemy tak, by wykreować korzyści dla interesariuszy (by przynosiło to wartość) dzięki częstemu i regularnemu dostarczaniu ukończonych (ang. done) Przyrostów. Ta potrzeba skuteczności implikuje potrzebę dążenia do jak najwyższej efektywności (ang. efficiency). Nie da się tego zrobić bez ścisłej współpracy Developerów z Product Ownerem i bez Scrum Mastera, który nauczy, jak używać Scruma i pomoże zbudować środowisko, w którym metoda ta ma szansę dobrze funkcjonować.

Najnowszy Scrum Guide definiuje więc tylko jeden Zespół Scrum, w którym znajdują się Developerzy, Product Owner i Scrum Master, rozumiani nie jako zawody lub role, ale jako odpowiedzialności konkretnych osób tworzących Zespół.

Odpowiedzialności zamiast ról

Bardzo często na pytanie, czym się zajmują, Scrum Masterzy i Product Ownerzy odpowiadają: „pełnię rolę Scrum Mastera” lub „pełnię rolę Product Ownera”. Dużo rzadziej słyszymy „jestem Scrum Masterem” albo „jestem Product Ownerem”. Przy czym nierzadko ci, co „pełnią rolę” nie czują odpowiedzialności, jaka się z tym wiąże, bo rola jest dla nich czymś tymczasowym, przerwą w pełnieniu innych (ważniejszych) obowiązków i ról. Natomiast ci, co „są Product Ownerem” i „są Scrum Masterem”, potrafią zasklepić się w wąskich ramach definicji roli, traktując ją nierzadko jako osobny zawód i powstrzymując się od działań niezbędnych dla efektywności Zespołu, bo nie pasują one do ich rozumienia roli, w jakiej pracują.

Myślenie o rolach, a nie o konkretnych osobach, które przyjmują na siebie odpowiedzialność za coś, prowadzi do rozmycia tej odpowiedzialności. Nie służy to ani zapewnieniu przejrzystości niezbędnej do empirycznej kontroli procesu, ani efektywności w działaniu (ot, choćby szybkiemu podejmowaniu decyzji).

Zespół Scrum składa się z ludzi, a nie z ról. I to ci konkretni ludzie przyjmują na siebie jasno określone zobowiązania. Dlatego w nowym Scrum Guide zamiast o rolach jest mowa o odpowiedzialnościach.

I tu pierwsza ważna zmiana: cały Zespół Scrum odpowiada za zbudowanie wartościowego, działającego Przyrostu (jednego lub wielu kolejnych) w Sprincie. Zespół Scrum, a nie wyłącznie Developerzy. Scrum Master i Product Owner również. Są za to odpowiedzialni w znaczeniu angielskiego słowa accountable, bo choć niekoniecznie wszyscy będą budować produkt, wszyscy odpowiadają za to, by został zbudowany, był wartościowy i nadawał się do użycia (był ukończony).

Product Owner

Osoba będąca Product Ownerem odpowiada za wartość produktu, ale uwaga: nie tylko za to, by zdefiniować, co nią jest, ale przede wszystkim za wartość tego, co powstało. Odpowiedzialność Product Ownera nie kończy się więc na zdefiniowaniu elementów Backlogu Produktu i określeniu ich kolejności. Odpowiada on również za wartość tego, co znajdzie się rzeczywiście w Przyroście, jaki wytworzą Developerzy. Bo to cały Zespół Scrum (a nie tylko Developerzy) dostarcza Przyrost interesariuszom.

Developerzy

Osoby będące Developerami odpowiadają za wytworzenie Przyrostu, który jest nośnikiem wartości, jaką zidentyfikował Product Owner. Odpowiadają też za jakość produktu, a ciężko mówić o jakości, jeśli budowane jest coś, co nie ma wartości.

Dlatego Developerzy mają prawo i obowiązek wymagać od Product Ownera takiego działania, które pozwala wytworzyć wartość. Tak samo mają prawo i obowiązek wymagać od Scrum Mastera pomocy w usuwaniu utrudnień (ang. impediments), które przerastają ich możliwości. I wreszcie mają prawo i obowiązek wymagać od siebie wzajemnie profesjonalizmu i przestrzegania ustalonych standardów pracy.

Scrum Master

Osoba będąca Scrum Masterem odpowiada za doprowadzenie do sytuacji, w której Zespół stosuje świadomie Scrum do generowania korzyści (wartości) dla interesariuszy. Scrum Master jest więc wprost odpowiedzialny za skuteczność tego Zespołu.

Inaczej mówiąc, Scrum Master ponosi odpowiedzialność za to, by Developerzy i Product Owner potrafili wywiązać się ze swych odpowiedzialności i faktycznie to robili. Z tego wynika konieczność pracy zarówno z Zespołem Scrum, jak i jego otoczeniem (organizacją, interesariuszami, klientami itd.).

Samozarządzanie zamiast samoorganizacji

Skoro w Scrumie jest tylko jeden Zespół, powinien on być samoorganizujący się. Przy czym pojęcie samoorganizacji, używane do tej pory, również mogło wprowadzać w błąd (nawet jeśli już przywykliśmy do niego). Jest to bowiem termin dużo starszy niż sam Scrum opisujący poziom autonomii Zespołu. Samoorganizacja w tym ogólnym znaczeniu to autonomia członków Zespołu pozwalająca im decydować o jego składzie, odpowiedzialnościach, warunkach pracy itd.

Scrum nie wymaga aż tak wysokiego poziomu autonomii. Zespół Scrum organizuje sobie pracę w granicach i wedle zasad określonych przez organizację, która powołała Zespół do życia, określając, kto będzie Product Ownerem i konstruując Zespół niezbędny do zbudowania produktu. W praktyce oznacza to, że Zespół Scrum sam zarządza swoją pracą – zarządza, czyli zapewnia jej efektywne wykonanie.

Dlatego nowy Scrum Guide, zamiast o samoorganizacji, pisze o samozarządzaniu Zespołu Scrum. Przy czym nic nie stoi na przeszkodzie, by organizacje gotowe na to, tworzyły Zespoły samoorganizujące się.

Zobowiązania względem artefaktów

Artefakty w każdym procesie powstają jako wytwór tego procesu. Są albo nośnikiem wartości, jaką przyniosło użycie procesu, albo narzędziem dostarczającym informacje niezbędne do podejmowania decyzji. Nie inaczej jest w Scrumie: każdy artefakt stanowi podmiot inspekcji, który w ramach poszczególnych zdarzeń jest sprawdzany tak, by zapewnić przejrzystość – postępu prac, procesu, stanu produktu itd.

Pewną trudność użytkownikom Scruma stwarzała Definicja Ukończenia, która nie stanowiła osobnego elementu frameworku, tylko związana była z Przyrostem. Jeszcze większy kłopot sprawiał Cel Sprintu, który jawił się wielu osobom jako coś wirtualnego, niekoniecznie wprost związanego z konkretnym artefaktem (a przecież powiązany jest z Backlogiem Sprintu).

Nowy Scrum Guide wzmacnia każdy z artefaktów zobowiązaniem (ang. commitment). Zobowiązania te są swoistymi umowami, jakie zawierają sami ze sobą członkowie Zespołu Scrum. Są więc deklaracją tego, co i jak Zespół Scrum zamierza zrobić oraz w jaki sposób będzie nad tym pracował. Inaczej mówiąc, są deklaracją intencji Zespołu odnośnie do sposobu pracy i wartości, jaką będzie dostarczał interesariuszom.

Cel Produktu

To nowa rzecz, choć świadomych użytkowników Scruma w ogóle nie zdziwi. Jest to zobowiązanie związane z Backlogiem Produktu i ma zapewnić odpowiedź na pytanie o cel, dla którego Backlog Produktu ma w tym momencie taki a nie inny kształt. Można powiedzieć, że Backlog ten stanowi dynamicznie zmienny plan osiągnięcia wyznaczonego Celu Produktu.

Ponieważ jest tylko jeden Backlog związany z konkretnym produktem i stanowić on ma prostą listę (a nie szereg równoległych list), w każdym momencie istnieć może logicznie tylko jedna odpowiedź na pytanie o to, jaki skutek lub efekt ma przynieść realizacja elementów Backlogu. Dlatego obowiązujący Cel Produktu może być tylko jeden. Dopiero po jego osiągnięciu albo porzuceniu, można zdefiniować kolejny Cel Produktu.

Dlaczego Cel Produktu to zobowiązanie? Bo Zespół Scrum zobowiązuje się do osiągnięcia tego Celu w serii kolejnych Sprintów, skupiając się na nim (nie marnotrawiąc czasu na działania zbędne dla osiągnięcia aktualnego Celu Produktu).

Za zdefiniowanie Celu Produktu, co oczywiste, odpowiada Product Owner, który następnie ma zarządzać Backlogiem Produktu tak, by ku temu Celowi wraz z całym Zespołem podążać. Istotna uwaga jest taka: Cel Produktu stanowi integralną część Backlogu Produktu i choć nie jest kolejnym jego elementem, musi być w Backlogu widoczny. Inaczej mówiąc, każdy użytkownik Backlogu Produktu musi widzieć (bez domyślania się i szukania gdzieś indziej), jaki jest Cel Produktu. Jak to zrobić – pozostaje w gestii Product Ownera, który oczywiście może, a nawet powinien, uzgodnić to z całym Zespołem Scrum.

Cel Sprintu

To istniejące wcześniej pojęcie, które sprawia mnóstwo problemów, co samo w sobie jest znamienne, bo przecież Cel Sprintu odpowiada na pytanie „po co odbywa się ten Sprint?”. Brak dobrej odpowiedzi źle świadczy o sposobie, w jaki budowany jest Backlog Sprintu i nie wróży dużej skuteczności ani efektywności Zespołu.

Nowy Scrum Guide czyni z Celu Sprintu zobowiązanie związane z Backlogiem Sprintu. Cel Sprintu – to nowość – ma być widoczny w Backlogu Sprintu tak, by bez domyślania się i dopytywania dało się określić, do czego dąży Zespół w ramach bieżącej iteracji.

Zmianie – subtelnej, ale bardzo istotnej – ulega też znaczenie Celu Sprintu. Od teraz ma stanowić on odpowiedź na pytanie o wartość, jaką przyniesie ten Sprint interesariuszom. Cel Sprintu powinien też stanowić logiczny krok ku osiągnięciu Celu Produktu. W ten sposób karkołomne „składkowe” Cele Sprintu w rodzaju „zrobić wszystko” tracą rację bytu w Scrumie.

Dlaczego Cel Sprintu to zobowiązanie? Bo Zespół zobowiązuje się skupić na uzyskaniu tej wartości, której dostarczenie zdeklarował w trakcie Planowania Sprintu.

Warto zauważyć, że wynikiem istnienia takiego zobowiązania jest prawo Developerów, by oczekiwać od Scrum Mastera, Product Ownera lub innych Developerów zaangażowania w Sprint. Choć to głównie Developerzy pracują nad wywiązaniem się ze zobowiązania, jest ono wciąż zobowiązaniem całego Zespołu.

Definicja Ukończenia

To również istniejące od bardzo dawna pojęcie, jedno z kluczowych w Scrumie. Określa warunki, pod którymi wykonywane w Sprincie prace można uznać za ukończone. W praktyce determinuje, jakie cechy musi spełniać Przyrost i jaki powinien być proces jego wytworzenia, by Przyrostu można było użyć (potencjalnie, bo o faktycznym użyciu – lub wydaniu w przypadku niektórych produktów, np. oprogramowania – decydował Product Owner).

Nowy Scrum Guide czyni z Definicji Ukończenia zobowiązanie związane z Przyrostem.

Ponieważ mamy jeden Zespół Scrum, Definicja Ukończenia jest formułowana – na podstawie standardów obowiązujących w organizacji – przez cały Zespół. Pamiętać przy tym należy o odpowiedzialnościach poszczególnych osób. Z tego wynika różny wpływ na formę i zawartość Definicji Ukończenia:

• Product Owner ma prawo i obowiązek oczekiwać, że Przyrost będzie miał wartość, a to wymaga zapewnienia, że produkt może być użyty – wynikną z tego wymogi formalne (np. istnienie dokumentacji, zgodność z normami prawnymi), niefunkcjonalne (np. wydajność, bezpieczeństwo, ergonomia) albo procesowe (np. formalna certyfikacja przez jakąś instytucję).
• Developerzy mają prawo i obowiązek oczekiwać, że Definicja Ukończenia odzwierciedlać będzie ich możliwości i standardy, wedle których chcą pracować, w tym te wynikające z ogólnych norm obowiązujących w organizacji.
• Scrum Master ma prawo i obowiązek oczekiwać, że Definicja Ukończenia nie obniży możliwości działania empirycznego i pozwoli na jednoznaczne stwierdzenie, czy jest spełniona, czy też nie (czy powstał Przyrost, czy nie).

Z tych różnych odpowiedzialności i konieczności ich pogodzenia powstanie Definicja Ukończenia taka, którą realnie posłuży się Zespół Scrum (cały, a nie sami Developerzy).

Definicja Ukończenia ma przy tym zapewnić przejrzystość tego, co to znaczy ukończona praca w tym konkretnym Zespole i dla tego konkretnego produktu. Czasami skutkiem tego bywa ujawnienie różnicy między tym, co Developerzy potrafią wytworzyć, a czego potrzebuje Product Owner. Jak wybrnąć z tej sytuacji zależy indywidualnie od każdego Zespołu, ale kluczowe jest, by używana przez Zespół Definicja Ukończenia bezwzględnie odzwierciedlała to, co jest robione (a nie to, co kiedyś być może uda się zrobić).

Nowy Scrum Guide nie definiuje wyłącznego prawa Product Ownera do podejmowania decyzji o użyciu Przyrostu, czego logiczną implikacją jest, że zgodzić na to muszą się również Developerzy.  To dobrze, bo często tylko oni potrafią dobrze oszacować skutki użycia wczesnej wersji produktu, w którym wciąż brakuje wielu funkcjonalności.

Inspekcja, adaptacja i przejrzystość po nowemu

Trzy filary procesu empirycznego nie są niczym nowym, ale sposób, w jaki najnowszy Scrum Guide odnosi się do nich, jest wart komentarza.

Pierwsza istotna kwestia to podkreślenie, że celem inspekcji jest następująca po niej adaptacja. Inaczej mówiąc, dokonywanie sprawdzenia jest bezcelowe, jeśli nie towarzyszy temu gotowość realizacji działań dostosowujących, gdy tylko ujawni się taka potrzeba. Wydaje się to oczywiste, ale najwyraźniej nie jest takie dla wszystkich – w wielu Zespołach zdarzenia Scrum zamieniają się w spotkania statusowe służące zebraniu danych, ale nieprowadzące do podjęcia na ich podstawie jakichkolwiek decyzji, nie mówiąc o działaniach. W ten sposób stają się one bezwartościową stratą czasu.

Druga zmiana to skupienie procesu empirycznego wprost na wartości dla interesariuszy (użytkowników, klientów itd.) i skuteczności działania całego Zespołu Scrum. Przykładem takiej zmiany jest wskazanie, że sprawdzeniu na Przeglądzie Sprintu poddawany jest skutek wykonania prac w iteracji i powstania najnowszego Przyrostu (ang. outcome), a nie sam Przyrost. Małe znaczenie ma, czy zrobiona została taka, czy inna zmiana w produkcie, a kluczowe jest potwierdzenie, że jej dokonanie pozwoliło uzyskać oczekiwany efekt (dostarczyć wartość).

Wzmocnienie Scrum Mastera

Ważną zmianą, choć niepozorną, jest wzmocnienie osoby Scrum Mastera, którego odpowiedzialności zostały w końcu nazwane wprost:

• Stworzyć środowisko, w którym możliwe jest wykorzystanie empiryzmu do rozwiązywania złożonych problemów.
• Zapewnić, że Scrum jest używany świadomie i w sposób zgodny z definicją zawartą w Scrum Guide – przy czym chodzi to o faktyczne działanie wedle zasad frameworku, a nie wytworzenie pozornych artefaktów i realizowanie zdarzeń w sposób pozbawiony empiryzmu.
• Zapewnić skuteczność działania Zespołu Scrum – rozumianą jako umiejętność użycia praktyk niezbędnych do regularnego i częstego dostarczania wartości interesariuszom.

Bycie „mistrzem ceremonii”, człowiekiem od „robienia, by było miło” i „rozsiewaczem magicznego pyłku” nie pozwoli się z tych odpowiedzialności wywiązać. Podobnie jak zapomnienie lub brak świadomości, że Scruma używa się po to, by interesariusze zyskali więcej wartości, niż kosztuje ich inwestycja w Zespół.

To ważna zmiana przede wszystkim dlatego, że dla wielu osób Scrum Master stał się stanowiskiem pracy, a nierzadko osobnym zawodem. Ze stanowiskiem i zawodem wiążą się konkretne umiejętności i obowiązki – rozumiane jako określone czynności – ale niekoniecznie odpowiedzialność za skutki działania całego Zespołu. „Pełnienie roli Scrum Mastera” często rozmijało się z dążeniem do tego, by Scrum używany w Zespole faktycznie przynosił wartość interesariuszom, bo wysiłki szły na przykład głównie na rozwijanie dobrych relacji między Developerami (rzecz ważna, ale drugorzędna, środek do celu, a nie cel sam w sobie).

Tymczasem organizacja ma prawo (obowiązek nawet) wymagać od Scrum Mastera, by ten doprowadził Zespół (Developerów i Product Ownera) do możliwości częstego i regularnego dostarczania wartości dla interesariuszy. To kluczowa odpowiedzialność, zwłaszcza biorąc pod uwagę, że Scrum Master nie jest kierownikiem Zespołu i nie może wydawać poleceń ani zlecać wykonania konkretnych działań członkom Zespołu.

Nowy Scrum Guide może sprawić kłopot wielu Scrum Masterom, którzy trzymają się z dala od tematów developerskich i są nietechniczni, ale pracują z Zespołami mocno technicznymi, budującymi produkty silnie oparte o technologię. W praktyce mogą nie mieć szans, by wywiązać się z odpowiedzialności, jaka na nich spoczywa, o ile szybko nie zaczną się tych tematów developerskich uczyć. Bez podstawowej choćby wiedzy o tym, co większość osób w Zespole – czyli Developerzy – robią przez zasadniczą część czasu pracy w Scrumie, tacy Scrum Masterzy nawet nie będą mogli stwierdzić, czy Zespół działa efektywnie i jest skuteczny, już nie mówiąc o pomocy w skuteczności tej podnoszeniu.

Scrum to narzędzie

Scrum Guide 2020 przypadł nam do gustu z wielu powodów – prostota opisu, jasne nazwanie odpowiedzialności, jeden Zespół – to naprawdę dobre zmiany. Przy czym widzimy te zmiany jako lepsze, bardziej dobitne, jasne wyrażenie tego, czym Scrum był zawsze, a co niestety przez te lata stało się mniej czytelne.

W naszym odczuciu nowy Scrum Guide lepiej opisuje Scrum taki, jakim go poznaliśmy lata temu i jakim zawsze postrzegaliśmy. W szczególności wyraźniej niż do tej pory widać w nim, że Ken Schwaber i Jeff Sutherland oferują narzędzie zarządzania – proste, choć wymagające świadomego użycia, jeśli chce się uzyskać korzyści przy jego pomocy. Nie owijają też w bawełnę i piszą wprost: wartość, to korzyść, jaką dla interesariuszy wytwarza Zespół Scrum.

W czasach, gdy ruch Agile i Scrum będący jego częścią również, zaczyna być traktowany jako filozofia, zawód czy nawet styl życia, ten nowy Scrum Guide pozwala mieć nadzieję na przywrócenie niektórym pojęciom ich pierwotnego znaczenia.

Kiedy zmienią się szkolenia i egzaminy Scrum.org?

Do 9 stycznia 2021 włącznie, egzaminy certyfikacyjne będą przeprowadzane według Scrum Guide opublikowanego w 2017. 10 stycznia 2021 egzaminy będą niedostępne. Od 11 stycznia 2021 egzaminy będą się odbywać zgodnie z zapisami w nowym Scrum Guide z 2020.

Wszystkie kody pozwalające przystąpić do egzaminów, wystawione przed wspomnianą datą graniczną 10 stycznia 2021, zachowają oczywiście ważność. Zmiana jest wprowadzana stopniowo, aby dać przystępującym do egzaminów czas na zapoznanie się z nowym Scrum Guide. Scrum.org uważa, że byłoby nie fair kazać ludziom natychmiast zdawać egzaminy według nowego Scrum Guide, z którym nie mieli okazji się wcześniej zapoznać.

W związku z tym również materiały akredytowanych szkoleń nie będą zmienione do końca bieżącego roku. Natomiast w każdym naszym szkoleniu znajdzie się blok poświęcony omówieniu zmian wprowadzanych w Scrum Guide 2020.