W Scrumie występują trzy główne odpowiedzialności: Product Owner, Scrum Master i Developers. Razem tworzą jeden Scrum Team, który odpowiada za stworzenie wartościowego i użytecznego Incrementu w każdym Sprincie. Product Owner koncentruje się na wartości produktu, Developers na stworzeniu rozwiązania, a Scrum Master na skuteczności zespołu i właściwym stosowaniu Scrum.
Popularnie mówi się o rolach w Scrumie, jednak aktualny Scrum Guide używa określenia accountabilities, czyli odpowiedzialności. Zmiana terminologii została wprowadzona w 2020 roku, aby podkreślić, że Product Owner, Scrum Master i Developer nie są po prostu stanowiskami w strukturze firmy. Określają zakres odpowiedzialności potrzebny do działania Scrum.
To istotne rozróżnienie. Osoba zatrudniona jako tester, UX designer, analityk czy DevOps Engineer może należeć do Developers. Product Owner nie musi mieć stanowiska o dokładnie takiej nazwie w firmowej strukturze. Scrum Master nie jest natomiast kierownikiem zespołu tylko dlatego, że odpowiada za skuteczność stosowania Scrum.
Jakie są role w Scrumie?
Scrum Team składa się z:
- jednego Product Ownera,
- jednego Scrum Mastera,
- Developers.
Wewnątrz Scrum Teamu nie ma podzespołów ani formalnej hierarchii. Zespół jest interdyscyplinarny i samodzielnie zarządza swoją pracą. Według Scrum Guide Scrum Team liczy zazwyczaj 10 osób lub mniej, choć nie jest to sztywny limit.
Najważniejsze różnice można sprowadzić do trzech obszarów:
| Odpowiedzialność | Główny obszar | Najważniejsze pytanie |
|---|---|---|
| Product Owner | Wartość produktu | Nad czym warto pracować i dlaczego? |
| Developers | Stworzenie Incrementu | Jak osiągniemy Sprint Goal i stworzymy użyteczne rozwiązanie? |
| Scrum Master | Skuteczność Scrum Teamu | Jak pomóc zespołowi skuteczniej wykorzystywać Scrum? |
Nie oznacza to podziału na biznes, wykonawców i kierownika procesu.
Cały Scrum Team wspólnie odpowiada za tworzenie wartościowego i użytecznego Incrementu w każdym Sprincie. Poszczególne odpowiedzialności określają natomiast obszary, za które konkretne osoby odpowiadają szczególnie.
Product Owner – odpowiedzialność za wartość produktu
Product Owner odpowiada za maksymalizowanie wartości produktu będącego rezultatem pracy Scrum Teamu.
To znacznie więcej niż zarządzanie listą zadań.
Scrum Guide przypisuje Product Ownerowi również odpowiedzialność za skuteczne zarządzanie Product Backlogiem, obejmujące:
- rozwijanie i jasne komunikowanie Product Goal,
- tworzenie i komunikowanie Product Backlog Items,
- ustalanie ich kolejności,
- zapewnienie, że Product Backlog jest przejrzysty, widoczny i zrozumiały.
Product Owner może część tych czynności delegować, ale odpowiedzialność pozostaje po jego stronie.
Product Owner nie jest sekretarzem backlogu
Słaby model Product Ownera wygląda tak:
interesariusze zgłaszają wymagania → Product Owner wpisuje je do backlogu → Developers je realizują.
W takim układzie Product Owner pełni funkcję pośrednika, ale nie zarządza wartością.
Dobry Product Owner musi podejmować decyzje.
Jeżeli do backlogu trafiają cztery inicjatywy, a zespół może zrealizować tylko jedną, ktoś musi ustalić, która z nich najbardziej przybliża produkt do Product Goal.
To może wymagać uwzględnienia:
- potrzeb użytkowników,
- wartości biznesowej,
- ryzyka,
- kosztu opóźnienia,
- wiedzy zdobytej z poprzednich Incrementów,
- możliwości technicznych,
- sytuacji rynkowej.
Scrum nie podaje wzoru matematycznego do ustalania priorytetów. Product Owner odpowiada za decyzję, ale sposób jej podejmowania zależy od konkretnego produktu i organizacji.
Product Owner jest jedną osobą
Scrum Guide mówi wprost: Product Owner jest jedną osobą, a nie komitetem.
Może reprezentować potrzeby wielu interesariuszy, ale osoby chcące zmienić Product Backlog powinny przekonać Product Ownera do swojej propozycji.
To ważne praktycznie.
Jeżeli pięciu dyrektorów może bezpośrednio wrzucać Developers nowe zadania o najwyższym priorytecie, Product Owner nie ma realnej możliwości zarządzania wartością.
Organizacja musi więc respektować decyzje Product Ownera dotyczące Product Backlogu.
Czy Product Owner sam ustala Sprint Goal?
Nie. Podczas Sprint Planning cały Scrum Team współpracuje nad Sprint Goal. Product Owner wnosi wiedzę o wartości, Product Goal i najważniejszych elementach Product Backlogu, a Developers oceniają, co mogą wykonać w Sprincie.
To jeden z przykładów pokazujących, dlaczego Scrum nie działa dobrze jako model:
Product Owner zleca → Developers wykonują.
Sprint Goal powinien powstawać poprzez współpracę.
Scrum Master – odpowiedzialność za skuteczność Scrum Teamu
Scrum Master odpowiada za ustanowienie Scrum zgodnie ze Scrum Guide oraz za skuteczność Scrum Teamu.
Pomaga ludziom w zespole i organizacji rozumieć teorię i praktykę Scrum oraz wspiera Scrum Team w poprawianiu sposobu pracy.
To znacznie szersze ujęcie niż popularna definicja:
Scrum Master organizuje spotkania i usuwa blokery.
Te działania mogą być częścią pracy Scrum Mastera, ale jej nie wyczerpują.
Co robi Scrum Master?
Scrum Guide wskazuje między innymi:
- coaching zespołu w zakresie self-management i cross-functionality,
- pomaganie zespołowi koncentrować się na wartościowych Incrementach zgodnych z Definition of Done,
- powodowanie usuwania przeszkód ograniczających postęp,
- dbanie, aby wydarzenia Scrum się odbywały oraz były produktywne i mieściły się w timeboxach.
Scrum Master wspiera również Product Ownera, m.in. przy:
- definiowaniu Product Goal,
- zarządzaniu Product Backlogiem,
- empirycznym planowaniu produktu,
- współpracy z interesariuszami.
Jego odpowiedzialność wykracza też poza sam Scrum Team. Scrum Master może pomagać organizacji we wdrażaniu Scrum, usuwać bariery między zespołami a interesariuszami oraz wspierać zmianę sposobu pracy.
Scrum Master nie jest kierownikiem zespołu
Scrum Master nie:
- przydziela Developers zadań,
- ocenia ich indywidualnej produktywności,
- zatwierdza urlopów dlatego, że jest Scrum Masterem,
- decyduje, jak Developers mają wykonać Sprint Backlog,
- zarządza nimi jak klasyczny Team Leader.
Scrum Team jest self-managing. Sam decyduje, kto, kiedy i jak wykonuje pracę.
Scrum Master może pomóc zespołowi poprawić sposób podejmowania tych decyzji, ale nie powinien przejmować ich za zespół.
Scrum Master nie musi prowadzić każdego spotkania
To częsty antywzorzec.
Scrum Master ma zapewnić, że wydarzenia Scrum się odbywają i realizują swój cel. Nie oznacza to obowiązku prowadzenia każdego Sprint Planning, Daily Scrum, Review czy Retrospective.
Szczególnie widoczne jest to przy Daily Scrum.
Daily Scrum jest wydarzeniem dla Developers. Służy kontroli postępu w kierunku Sprint Goal i dostosowaniu Sprint Backlogu.
Jeżeli Scrum Master codziennie prowadzi spotkanie i odpytuje każdego:
- co zrobiłeś wczoraj,
- co zrobisz dzisiaj,
- czy masz problem,
Daily może szybko zmienić się w raport statusowy dla Scrum Mastera zamiast narzędzia Developers do zarządzania własnym planem.
Developers – kto to jest w Scrumie?
Developers to osoby w Scrum Teamie odpowiedzialne za tworzenie dowolnego elementu użytecznego Incrementu w każdym Sprincie.
Słowo Developer często prowadzi do błędnego wniosku, że chodzi wyłącznie o programistów.
Scrum Guide wyraźnie zaznacza jednak, że Scrum jest dziś stosowany daleko poza developmentem oprogramowania i określenie Developers jest używane dla uproszczenia. Kompetencje potrzebne do stworzenia Incrementu zależą od charakteru produktu.
W zespole software’owym Developers mogą więc obejmować przykładowo:
- software developerów,
- testerów,
- UX/UI designerów,
- analityków,
- specjalistów DevOps,
- data engineerów,
jeżeli ich praca jest potrzebna Scrum Teamowi do stworzenia użytecznego Incrementu.
Nie tworzy się wtedy osobnego zespołu testerskiego wewnątrz Scrum Teamu.
Za co odpowiadają Developers?
Scrum Guide określa cztery podstawowe odpowiedzialności Developers:
- stworzenie planu Sprintu, czyli Sprint Backlogu,
- zapewnienie jakości poprzez przestrzeganie Definition of Done,
- codzienne dostosowywanie planu w kierunku Sprint Goal,
- wzajemne rozliczanie się ze swoich profesjonalnych zobowiązań.
To istotnie różni się od przedstawiania Developers jako osób, które po prostu realizują zadania przygotowane przez Product Ownera.
Kto decyduje, jak wykonać pracę?
Developers.
Product Owner może opisywać potrzebę, cel i kontekst biznesowy. Może współpracować z zespołem nad doprecyzowaniem Product Backlog Items.
Nie powinien jednak narzucać Developers szczegółowego planu technicznego.
Przykład:
Product Owner może określić, że klient powinien móc samodzielnie zmienić adres dostawy przed wysyłką zamówienia.
Decyzje dotyczące:
- architektury,
- zmian backendu,
- testów,
- sposobu integracji,
- kolejności technicznych działań
należą do osób wykonujących pracę.
Scrum Team jest self-managing właśnie po to, aby decyzje dotyczące wykonania podejmowali ludzie posiadający odpowiedni kontekst i kompetencje.
Product Owner, Scrum Master i Developers – kto za co odpowiada?
| Obszar | Product Owner | Scrum Master | Developers |
| Maksymalizacja wartości produktu | Odpowiada | Wspiera | Współpracują |
| Product Goal | Odpowiada za rozwijanie i komunikowanie | Wspiera | Współpracują |
| Zarządzanie Product Backlogiem | Odpowiada | Wspiera | Uczestniczą w doprecyzowaniu |
| Kolejność Product Backlogu | Odpowiada | Nie ustala | Mogą wnosić wiedzę |
| Sprint Goal | Współtworzy | Wspiera proces | Współtworzą |
| Sprint Backlog | Wnosi kontekst | Wspiera | Odpowiadają za plan |
| Sposób wykonania pracy | Nie narzuca | Nie narzuca | Decydują |
| Definition of Done | Scrum Team | Scrum Team | Stosują przy tworzeniu Incrementu |
| Skuteczność Scrum Teamu | Współtworzy | Odpowiada | Współtworzą |
| Usuwanie przeszkód | Może pomagać | Powoduje ich usuwanie | Aktywnie rozwiązują problemy |
| Increment | Wspólny rezultat Scrum Teamu | Wspólny rezultat Scrum Teamu | Tworzą jego elementy |
Tabela pokazuje również, dlaczego uproszczenie:
PO = biznes, SM = proces, Developers = wykonawcy
jest niewystarczające.
Scrum Team ma działać jako jedna jednostka skupiona na Product Goal.
Jak role w Scrumie współpracują podczas Sprint Planning?
Sprint Planning angażuje cały Scrum Team.
Spotkanie odpowiada na trzy główne obszary:
- dlaczego Sprint jest wartościowy,
- co można wykonać,
- jak wybrana praca zostanie wykonana.
Product Owner wnosi informacje o Product Goal, wartości i najważniejszych elementach Product Backlogu.
Developers wybierają elementy, które są w stanie wykonać, i tworzą plan pracy.
Scrum Team wspólnie formułuje Sprint Goal.
Scrum Master dba o to, aby Scrum był rozumiany i wydarzenie spełniało swój cel.
To współpraca, a nie przekazanie listy zadań przez Product Ownera zespołowi wykonawczemu.
Jak wygląda współpraca podczas Daily Scrum?
Daily Scrum jest wydarzeniem Developers.
Celem jest sprawdzenie postępu w kierunku Sprint Goal i odpowiednie dostosowanie planu dalszej pracy.
Product Owner i Scrum Master mogą być obecni, jeżeli wykonują pracę jako Developers dotyczącą elementów Sprint Backlogu, ale nie są domyślnymi odbiorcami statusu.
Dobre Daily pomaga Developers odpowiedzieć na praktyczne pytanie:
Co powinniśmy dziś zmienić w naszym planie, aby zwiększyć szansę osiągnięcia Sprint Goal?
Jeżeli niczego nie można dostosować, a spotkanie polega wyłącznie na raportowaniu aktywności, warto sprawdzić, czy realizuje swoją funkcję.
Jak role współpracują podczas Sprint Review?
Sprint Review nie jest prezentacją przygotowaną przez Developers dla Product Ownera.
Scrum Team wspólnie z interesariuszami analizuje wynik Sprintu oraz zmiany, które zaszły w otoczeniu produktu.
Product Owner wnosi perspektywę produktową i biznesową.
Developers mogą wyjaśnić Increment, problemy techniczne czy możliwości dalszego rozwoju.
Interesariusze przekazują feedback i nowe informacje.
Scrum Team wykorzystuje zdobyte informacje do adaptacji dalszych działań.
Product Backlog może zostać odpowiednio zmieniony.
Jak role współpracują podczas Retrospektywy Sprintu?
Retrospektywa dotyczy całego Scrum Teamu.
Nie jest spotkaniem, podczas którego Scrum Master ocenia Developers.
Product Owner również jest członkiem Scrum Teamu i uczestniczy w analizie sposobu pracy.
Zespół może rozmawiać m.in. o:
- współpracy,
- komunikacji,
- przepływie pracy,
- jakości,
- Definition of Done,
- narzędziach,
- procesach,
- blokadach.
Scrum Master może facylitować rozmowę, ale nie musi być jedyną osobą odpowiedzialną za wymyślanie usprawnień.
Najczęstsze błędy w rozumieniu ról Scrum
Product Owner jako osoba zapisująca wymagania
Jeżeli Product Owner jedynie przepisuje oczekiwania interesariuszy do Jiry, nie wykorzystuje swojej podstawowej odpowiedzialności za wartość.
Musi mieć możliwość dokonywania wyborów i odrzucania inicjatyw.
Scrum Master jako Project Manager
Jeżeli Scrum Master:
- przypisuje zadania,
- zarządza terminami poszczególnych osób,
- kontroluje status,
- zatwierdza sposób wykonania pracy,
zespół traci self-management.
Scrum Master powinien zwiększać zdolność zespołu do samodzielnego działania, a nie stawać się centrum każdej decyzji.
Developers jako sami programiści
To często prowadzi do tworzenia osobnych silosów:
development → testy → analiza → deployment.
Scrum zakłada cross-functional Scrum Team posiadający kompetencje potrzebne do tworzenia wartości w każdym Sprincie.
Product Owner jako komitet
Jeżeli kilka osób musi wspólnie zatwierdzić każdą decyzję backlogową, podejmowanie decyzji może stać się wąskim gardłem.
Scrum jasno przypisuje accountability Product Ownera jednej osobie.
Scrum Master jako organizator kalendarza
Samo wysłanie zaproszeń na Daily i Retrospective nie oznacza jeszcze realizowania odpowiedzialności Scrum Mastera.
Znacznie ważniejsze jest pytanie:
Czy Scrum Team z czasem staje się bardziej skuteczny i samodzielny?
Czy jedna osoba może pełnić dwie role w Scrumie?
Scrum Guide nie wprowadza ogólnego zakazu łączenia odpowiedzialności przez jedną osobę.
Nie oznacza to jednak, że każde połączenie jest dobrym pomysłem.
Szczególnie problematyczne może być połączenie Product Ownera i Scrum Mastera.
Product Owner odpowiada za maksymalizowanie wartości i podejmuje decyzje dotyczące Product Backlogu.
Scrum Master odpowiada za skuteczność zespołu i powinien pomagać tworzyć środowisko, w którym inni mogą otwarcie kwestionować sposób pracy.
Połączenie obu odpowiedzialności może powodować koncentrację wpływu oraz konflikty interesów. Scrum.org zwraca uwagę, że choć Scrum Guide formalnie tego nie zabrania, połączenie Product Ownera i Scrum Mastera zwykle nie jest rozsądnym modelem.
Czy w Scrumie jest Project Manager?
Project Manager nie jest jedną z odpowiedzialności zdefiniowanych przez Scrum.
Nie oznacza to jednak, że osoba zatrudniona jako Project Manager musi zniknąć z organizacji.
Jej dotychczasowe obowiązki mogą:
- przestać być potrzebne,
- trafić do Product Ownera,
- trafić do Developers,
- być realizowane przez Scrum Mastera,
- pozostać poza Scrum Teamem jako część szerszej struktury organizacyjnej.
Nie warto jednak mechanicznie zamieniać Project Managera w Scrum Mastera.
To dwa różne sposoby rozumienia odpowiedzialności.
Scrum został zaprojektowany wokół self-managing Scrum Teamu, dlatego nie potrzebuje roli kierownika przydzielającego zespołowi pracę.
Czy Team Leader jest rolą w Scrumie?
Nie, Scrum Guide nie definiuje odpowiedzialności Team Leadera.
Organizacja może mieć takie stanowisko ze względów HR, technologicznych lub organizacyjnych, ale Team Leader nie otrzymuje z tego powodu dodatkowych uprawnień wewnątrz frameworka Scrum.
Jeżeli techniczny lider pomaga zespołowi podejmować decyzje architektoniczne, może robić to jako jeden z Developers.
Problem pojawia się wtedy, gdy formalny Team Leader zaczyna:
- jednoosobowo przydzielać pracę,
- decydować za zespół, jak wykonać Sprint,
- zatwierdzać każdą decyzję techniczną.
Wtedy self-management istnieje tylko z nazwy.
Jak rozpoznać dobrze działający podział odpowiedzialności?
Nie trzeba analizować nazw stanowisk.
Lepiej obserwować, gdzie podejmowane są decyzje.
Product Owner powinien być w stanie odpowiedzieć:
Jaki cel produktu realizujemy i dlaczego obecne priorytety mają największą wartość?
Developers:
Jak zamierzamy osiągnąć Sprint Goal i czy nasz plan nadal jest właściwy?
Scrum Master:
Co ogranicza skuteczność Scrum Teamu i jak możemy pomóc zespołowi poprawić sposób pracy?
Jeżeli zamiast tego:
- interesariusze bezpośrednio zmieniają backlog,
- Scrum Master przydziela zadania,
- Developers czekają na szczegółowe instrukcje,
- Product Owner nie może podejmować decyzji,
- każdy problem musi zatwierdzić manager,
same nazwy Product Owner, Scrum Master i Developer niewiele zmieniają.
Role w Scrumie działają wtedy, gdy wraz z odpowiedzialnością istnieje realna możliwość podejmowania decyzji w danym obszarze. Product Owner potrzebuje przestrzeni do zarządzania wartością, Developers do samodzielnego organizowania wykonania pracy, a Scrum Master do wspierania zmian zwiększających skuteczność zespołu. Scrum Team jako całość pozostaje natomiast odpowiedzialny za stworzenie wartościowego, użytecznego Incrementu w każdym Sprincie.
