Scrum — role, wydarzenia i artefakty

Scrum pomaga zespołom tworzyć wartość przez adaptacyjne rozwiązywanie złożonych problemów. Jest ramą postępowania, nie gotowym procesem ani techniką.¹
Podstawą Scruma jest empiryzm: zespół podejmuje decyzje na podstawie doświadczenia i zaobserwowanych rezultatów.¹ W artykule omawiamy odpowiedzialności, wydarzenia i artefakty, a także pracę w sprintach oraz rolę narzędzi. Punktem odniesienia jest Scrum Guide opublikowany w 2020 roku².

Czym jest Scrum i skąd się wziął?

Opisany w Scrum Guide Scrum skupia pracę zespołu wokół wspólnego celu i regularnej oceny wyników.
Nie jest szczegółowym planem projektu: nie wskazuje kolejności poszczególnych zadań ani narzędzia do ich zapisywania. Ken Schwaber i Jeff Sutherland po raz pierwszy publicznie przedstawili Scrum w 1995 roku na konferencji OOPSLA³.

Scrum opiera się na przejrzystości, inspekcji i adaptacji.¹
Zespół pokazuje stan pracy, sprawdza jej wyniki i odpowiednio zmienia dalsze działania. To 3 filary empiryzmu w Scrumie³.

Scrum wymienia też zaangażowanie, odwagę, skupienie, otwartość i szacunek.¹ Te wartości pomagają rozmawiać o przeszkodach, trzymać się celu i wspólnie podejmować decyzje. Przewodnik wskazuje łącznie 5 wartości Scruma³.

Jakie wydarzenia porządkują pracę zespołu?

Pracę wyznaczają sprint oraz odbywające się w nim planowanie, Daily Scrum, przegląd i retrospektywa.
Podczas planowania zespół ustala kierunek, a na Daily Scrum Deweloperzy dostosowują bieżący plan. Przegląd służy ocenie rezultatu; retrospektywa dotyczy sposobu współpracy. Daily Scrum trwa maksymalnie 15 minut³.

Gdzie można stosować tę metodę pracy?

Scrum znajduje zastosowanie także poza IT, między innymi w marketingu, finansach i produkcji przemysłowej.¹
W tych dziedzinach zespoły również mierzą się ze złożonymi problemami, oceniają wyniki i zmieniają plany. O przydatności Scruma przesądza charakter pracy, nie nazwa działu. W badaniu State of Agile Marketing 2022 Scrum wskazało 17% marketerów stosujących Agile jako podejście najbliższe pracy ich działu⁴.

Jak powstała koncepcja pracy w sprintach?

Praca w sprintach wyrasta z podejścia do rozwoju produktu, w którym zespół współpracuje i wyciąga wnioski z rezultatów.
Hirotaka Takeuchi i Ikujiro Nonaka użyli określenia „scrum” w kontekście rozwoju produktu w 1986 roku.¹ Ich opis stał się punktem odniesienia dla późniejszych zasad pracy zespołowej.

Jak rozwijało się to podejście?

Scrum przeszedł drogę od opisu pracy nad produktem do zasad zawartych w Scrum Guide.
Jeff Sutherland i Ken Schwaber wspólnie przedstawili „Scrum Development Process” w 1995 roku.¹ Ostatnia aktualizacja Scrum Guide wskazana w źródle pochodzi z listopada 2020 roku.¹

Scrum łączy wspólne zasady współpracy z regularnym sprawdzaniem rezultatów. Przewiduje 5 wydarzeń służących inspekcji i adaptacji, wliczając Sprint³.

Czym jest proces pracy w sprintach i jak dzieli się odpowiedzialność?

Scrum dzieli pracę na kolejne sprinty. Odpowiedzialność w Scrum Teamie obejmuje 3 obszary: kierunek rozwoju produktu, skuteczność stosowania Scruma oraz tworzenie przyrostu.⁵
Przyrost jest ukończoną częścią produktu, którą można ocenić. Sprint trwa maksymalnie 1 miesiąc³.

Zespół ustala cel sprintu, wykonuje pracę i sprawdza jej rezultat.
Podział odpowiedzialności wskazuje, kto dba o produkt, kto wspiera sposób pracy, a kto tworzy przyrost. Nie zastępuje jednak współpracy. Przewodnik wyróżnia 3 zakresy odpowiedzialności: Product Ownera, Scrum Mastera i Developerów³.

Jak przebiega praca w kolejnych sprintach?

Sprint wyznacza czas na pracę nad uzgodnionym celem. Po jego zakończeniu zespół wykorzystuje wnioski do planowania dalszych działań. W danym sprincie pracę ukierunkowuje 1 Cel Sprintu³.

• Cel sprintu opisuje rezultat, do którego zespół dąży w tym okresie.
• Realizacja pracy obejmuje tworzenie przyrostu i korygowanie planu wraz z postępami.
• Ocena rezultatu pomaga uwzględnić informacje zwrotne w dalszym rozwoju produktu.

W kolejnym sprincie zespół może już pracować według planu zmienionego pod wpływem tych wniosków.
Przerwa między sprintami wynosi 0 dni: następny zaczyna się natychmiast po zakończeniu poprzedniego³.

Jakie korzyści może przynieść stosowanie zasad?

Scrum pozwala wcześniej ocenić wyniki pracy i skorygować kierunek przed podjęciem kolejnych zadań. Wspólny cel pomaga wybrać pracę służącą produktowi.
Ocena przyrostu odróżnia ukończony rezultat od samego postępu prac. Przy sprincie trwającym miesiąc Sprint Review trwa maksymalnie 4 godziny³.

Jakie trzy obszary odpowiedzialności obejmuje zespół?

Scrum Team odpowiada za wartość produktu, skuteczność stosowania Scruma i tworzenie użytecznego przyrostu. Każdy z tych obszarów dotyczy czegoś innego: kierunku rozwoju, sposobu współpracy albo wykonania pracy.
Wszyscy członkowie zespołu pracują jednak na wspólny cel produktu. Według przewodnika Scrum Team zwykle liczy 10 osób lub mniej³.

Za co odpowiadają Product Owner, Scrum Master i Deweloperzy?

Product Owner, Scrum Master i Deweloperzy mają odrębne odpowiedzialności w Scrum Teamie. Funkcję Product Ownera pełni 1 osoba, nie komitet³.

• Product Owner odpowiada za wizję produktu i zarządzanie backlogiem produktu, czyli uporządkowaną listą pracy potrzebnej do jego rozwoju.¹
• Scrum Master odpowiada za skuteczność stosowania Scruma i pomaga usuwać przeszkody utrudniające pracę zespołu.
• Deweloperzy planują i wykonują pracę potrzebną do stworzenia przyrostu produktu.

Ten podział wskazuje odpowiedzialność za każdy obszar, a wspólny cel spaja działania zespołu.
Zespół musi osiągnąć lub porzucić 1 Cel Produktu, zanim zacznie realizować następny³.

Czym są artefakty i wydarzenia w Scrumie?

Scrum wykorzystuje artefakty, by pokazać stan pracy nad produktem, oraz wydarzenia, by oceniać postępy i zmieniać plan.
Artefakty wskazują, nad czym zespół pracuje i co już ukończył. Wydarzenia wyznaczają czas na wspólne planowanie i ocenę. Scrum obejmuje 3 artefakty i 5 wydarzeń³.

Czym są artefakty i do czego służą?

Artefakty Scruma to backlog produktu, backlog sprintu i przyrost. Pierwszy jest aktualizowaną listą wymagań. Backlog sprintu zawiera cel sprintu, wybrane elementy backlogu produktu i plan ich realizacji.^1,6
Przyrost to gotowy do użycia fragment produktu, który spełnia definicję ukończenia.¹

Czym są wydarzenia i jak wspierają pracę zespołu?

Wydarzenia Scruma pomagają wspólnie wyznaczyć kierunek pracy, ocenić wynik i dostosować plan. Wraz ze Sprintem jest ich 5³.

• Planowanie sprintu pozwala ustalić cel i pracę potrzebną do jego osiągnięcia.
• Daily Scrum pozwala Deweloperom ocenić postęp i dostosować bieżący plan.
• Przegląd sprintu służy ocenie przyrostu, a retrospektywa – poprawie sposobu pracy zespołu.

Po wydarzeniach zespół powinien wiedzieć, co zrobi dalej. Samo przedstawienie statusu zadań nie wystarczy.

Jakie zobowiązania są powiązane z artefaktami?

Każdy z 3 artefaktów Scruma wiąże się ze zobowiązaniem. Wskazuje ono kierunek pracy albo warunek uznania rezultatu za ukończony:

• Backlog produktu wiąże się z celem produktu.¹
• Backlog sprintu wiąże się z celem sprintu.¹
• Przyrost wiąże się z definicją ukończenia.¹

Jakie trudności pojawiają się przy stosowaniu tej metody?

Scrum traci użyteczność, gdy zespół zapisuje zadania, ale nie ocenia wyników. Podobnie dzieje się wtedy, gdy wydarzenia nie prowadzą do decyzji.
Problemy widać po sposobie korzystania z 3 artefaktów i wydarzeń:

• Nieaktualny backlog produktu utrudnia wybór pracy odpowiadającej bieżącym potrzebom produktu.
• Niejasny cel sprintu utrudnia ocenę, czy zadania prowadzą do wspólnego rezultatu.
• Nieuzgodniona definicja ukończenia nie pozwala jasno rozstrzygnąć, czy fragment produktu jest gotowy do użycia.
• Stosowanie tylko wybranych elementów Scruma utrudnia powiązanie planowania, oceny rezultatów i zmian w sposobie pracy³.

O stosowaniu Scruma więcej mówią podjęte decyzje i ukończone rezultaty niż liczba odbytych spotkań.

Artefakty pokazują stan produktu. Wydarzenia pomagają wykorzystać tę wiedzę przy planowaniu dalszej pracy.

Czym jest zespół scrumowy i jak jest zorganizowany?

Scrum Team sam zarządza pracą nad produktem. Nie dzieli się na podzespoły i nie ma w nim hierarchii.⁵
Jego członkowie wspólnie uzgadniają sposób osiągnięcia celu, zamiast przekazywać zadania między szczeblami. Zespół zwykle liczy 10 osób lub mniej³.

Kto tworzy Scrum Team?

Scrum Team tworzą Scrum Master, Product Owner i Deweloperzy. Nie można więc utożsamiać go z samymi Deweloperami.⁵
Typowa wielkość Scrum Teamu to 10 lub mniej osób.⁵ Nazwy ról opisują odpowiedzialności w pracy nad produktem, nie osobne podzespoły.

Czym różni się cały zespół od Deweloperów?

Deweloperzy tworzą przyrost produktu. Cały Scrum Team odpowiada również za kierunek rozwoju produktu i skuteczność współpracy.
Interdyscyplinarność oznacza, że potrzebne umiejętności ma zespół jako całość, niekoniecznie każdy jego członek.⁵ Kompetencje należy więc oceniać na poziomie zespołu, a nie pojedynczej osoby³. Scrum Team zwykle liczy 10 osób lub mniej³.

Jak zespół współpracuje nad celem produktu?

Scrum Team uzgadnia kierunek pracy, tworzy przyrost i ocenia wyniki w odniesieniu do celu produktu. Cały zespół odpowiada za rozwój i dostarczanie produktu oraz rezultaty swojej pracy.⁵
Wspólny cel pozwala powiązać kolejne zadania z ich wpływem na produkt. Zespół pracuje nad 1 Celem Produktu, dopóki go nie osiągnie albo nie porzuci³.

Jaką samodzielność ma Scrum Team?

Scrum Team sam decyduje, kto wykona pracę, kiedy ją podejmie i jak ją zrealizuje.
Samodzielność dotyczy organizacji działań prowadzących do celu; nie zwalnia z oceny wyników. Gdy rezultat wskazuje potrzebę zmiany, zespół dostosowuje plan. Pracuje przy tym w sprintach trwających maksymalnie 1 miesiąc³.

Scrum Team łączy różne kompetencje. Jego członkowie wspólnie ustalają, jak wykonać pracę nad produktem.

Praca Scrum Mastera: zadania, przeszkody i zasady premiowania

Scrum Master pomaga zespołowi poprawiać sposób pracy i usuwać przeszkody. Nie przydziela Deweloperom zadań.
Wspiera zespół, Product Ownera i organizację w rozumieniu oraz stosowaniu Scruma, ale nie jest przełożonym zespołu.⁷ Scrum Team zwykle liczy 10 osób lub mniej³.

Jakie zadania wykonuje Scrum Master na co dzień?

Scrum Master dostrzega przeszkody utrudniające osiągnięcie celu i pomaga zespołowi je rozwiązać.
Dba też o to, by wydarzenia służyły planowaniu, ocenie wyników i decyzjom, a nie wyłącznie raportowaniu. Daily Scrum, z którego korzystają Deweloperzy, trwa maksymalnie 15 minut³.

Jak Scrum Master wspiera zespół i organizację?

Scrum Master pomaga we współpracy, gdy problem wykracza poza możliwości pojedynczego członka zespołu. Jego wsparcie obejmuje 3 obszary: zespół, Product Ownera i organizację⁷.

• Wsparcie zespołu ułatwia rozmowę o przeszkodach i zmianach w sposobie pracy.
• Wsparcie Product Ownera pomaga wyjaśniać cel i utrzymywać przejrzysty backlog.
• Wsparcie organizacji pomaga wskazać praktyki ograniczające samodzielność zespołu.

Jakie antywzorce utrudniają pracę zespołu?

Antywzorce w pracy Scrum Mastera to podejmowanie decyzji za zespół i traktowanie Daily Scrum jak raportu dla kierownika. Należy do nich także kończenie retrospektywy na liście skarg, bez ustalenia działań.
Takie praktyki ograniczają zdolność zespołu do planowania i poprawiania własnej pracy³. Daily Scrum trwa 15 minut i pomaga Deweloperom dostosować plan, a nie raportować przełożonemu³.

Od czego uzależnić premię Scrum Mastera?

Premię Scrum Mastera warto powiązać z uzgodnionymi, obserwowalnymi efektami jego pracy. Mogą one dotyczyć usuwania przeszkód i wdrażania usprawnień wskazanych przez zespół.
Sam wynik sprzedażowy produktu nie pozwala oddzielić wpływu Scrum Mastera od decyzji Product Ownera, pracy Deweloperów i warunków rynkowych. Kryteria powinny określać działania, na które ma wpływ, oraz sposób oceny wyników w ramach 3 obszarów odpowiedzialności Scrum Teamu³.

Wkład Scrum Mastera w poprawę współpracy mówi więcej o jego skuteczności niż liczba prowadzonych spotkań³.

Sprint krok po kroku: od planowania do retrospektywy

Sprint porządkuje pracę: zespół planuje cel, sprawdza postępy, pokazuje wynik i poprawia sposób działania.
Trwa maksymalnie 1 miesiąc. Często wybierane długości to 2 lub 4 tygodnie.^1,3

Tabela pokazuje działania podczas wydarzeń sprintu oraz ich limity czasu przy sprincie miesięcznym, zgodnie z przebiegiem pracy.

Dane w tabeli: 1,3,5

Według AppMaster na koniec sprintu powstaje co najmniej 1 przyrost.⁸
Zespół ocenia więc rezultat sprintu i ustala, co zmieni w dalszej pracy.

Wybór i ocena sposobu pracy zespołu

Scrum sprawdza się tam, gdzie zespół może regularnie pokazywać wynik, zbierać opinie i zmieniać plan.
O jego przydatności nie świadczy liczba zamkniętych zadań. Ważniejsze są postęp względem celu produktu i użyteczność rezultatów dostarczanych w sprintach trwających maksymalnie 1 miesiąc³.

Jak rozwijać umiejętności zespołu podczas pracy?

Zespół scrumowy rozwija umiejętności, gdy przekuwa wnioski w konkretne zmiany podczas kolejnego sprintu.
Retrospektywa sprintu miesięcznego trwa maksymalnie 3 godziny³.

• Retrospektywa pomaga wskazać przeszkodę lub umiejętność wymagającą rozwoju.
• Usprawnienie opisuje działanie, które zespół zastosuje w codziennej pracy.
• Ocena usprawnienia porównuje oczekiwany efekt z wynikiem zaobserwowanym po zmianie.

Wniosek z retrospektywy ma wartość wtedy, gdy zmienia sposób wykonania pracy.

Jakie potrzeby przemawiają za wyborem tej metody?

Scrum pomaga uczyć się na wynikach pracy nad złożonym produktem.
Wybierając sposób działania, zespół powinien ocenić poniższe potrzeby w odniesieniu do sprintu trwającego maksymalnie 1 miesiąc³:

• Zmienne wymagania przemawiają za regularnym dostosowywaniem zakresu dalszej pracy.
• Informacja zwrotna przemawia za pokazywaniem interesariuszom użytecznych wyników, nie tylko planów.
• Współpraca różnych specjalistów przemawia za wspólnym celem i uzgadnianiem sposobu wykonania pracy.

Przy wyborze Scruma potrzeba regularnej oceny produktu znaczy więcej niż samo używanie tablicy zadań.

Kiedy praca w sprintach pasuje do projektu?

Praca w sprintach pasuje do projektu, w którym zespół potrafi ustalić wspólny cel. Przed zaplanowaniem kolejnych działań powinien też móc ocenić ukończony wynik.
Jeśli głównym zajęciem jest obsługa napływających zgłoszeń bez wspólnego celu produktu, sprint nie rozwiązuje podstawowej potrzeby zespołu. Trwa maksymalnie 1 miesiąc, ale o jego wyborze decyduje możliwość uczenia się z wyników, nie sam podział kalendarza³.

Jak ocenić, czy zespół osiąga zamierzone efekty?

Ocena pracy zespołu powinna odnosić wynik do uzgodnionego celu, zamiast ograniczać się do liczenia zamkniętych zadań³.
Pracę w danym sprincie ukierunkowuje 1 Cel Sprintu³.

• Cel sprintu pomaga ustalić, czy praca przyniosła zamierzony rezultat.
• Przyrost produktu pokazuje, co zespół faktycznie ukończył i może wykorzystać.
• Informacje zwrotne pomagają ocenić, czy wynik odpowiada potrzebom interesariuszy.
• Usprawnienia zespołu pokazują, czy wnioski z retrospektywy zmieniły sposób pracy.

Scrum spełnia swoją funkcję, gdy ocena wyników prowadzi do świadomych decyzji o dalszej pracy.

Granice roli Scrum Mastera

Scrum Master nie zarządza projektem przez rozdzielanie zadań ani zatwierdzanie każdej decyzji zespołu. Nie rozlicza też poszczególnych osób z liczby ukończonych zadań.
Dba o warunki współpracy, nie przejmuje odpowiedzialności Product Ownera ani Deweloperów. Przewodnik wyróżnia 3 zakresy odpowiedzialności w Scrum Teamie³.

Kim Scrum Master nie jest?

Scrum Master nie jest kierownikiem, któremu zespół składa raport podczas Daily Scrum.
Deweloperzy wykorzystują to 15-minutowe spotkanie do uzgodnienia dalszej pracy. Odprawa statusowa dla jednej osoby ogranicza im możliwość dostosowania planu³. Scrum Master nie zastępuje również Product Ownera w decyzjach o kierunku produktu.

Wsparcie Scrum Mastera kończy się tam, gdzie zaczyna się podejmowanie decyzji za członków zespołu.

Scrum, Kanban i Agile: na czym polegają różnice?

Scrum jest ramą pracy w sprintach, Kanban pomaga zarządzać przepływem pracy, a Agile oznacza szersze podejście do współpracy i zmian. Agile nie jest inną nazwą Scruma ani Kanbanu.
Sprint w Scrumie trwa maksymalnie 1 miesiąc³.

Tabela porównuje Scrum, Kanban i Agile pod względem organizacji pracy oraz zakresu każdego pojęcia.

Dane w tabeli: 3,9

Oprogramowanie może pokazywać backlog sprintu lub tablicę Kanban. Sam widok zadań nie przesądza jednak o sposobie pracy.
Wybór zależy od tego, czy zespół pracuje wokół 1 Celu Sprintu, czy przede wszystkim zarządza przepływem napływających zadań³.

Ceny i warunki sprawdzone u źródeł: październik 2026.