Scrum – co to jest? Role, sprint i różnice z Kanbanem

Scrum to uproszczone ramy postępowania, które pomagają ludziom, zespołom i organizacjom wytwarzać wartość przez adaptacyjne rozwiązywanie złożonych problemów. Tak definiuje go Przewodnik po Scrumie z 2020 roku, napisany przez twórców metody, Kena Schwabera i Jeffa Sutherlanda. W praktyce wygląda to tak: zespół do około 10 osób pracuje w sprintach, czyli cyklach trwających najwyżej miesiąc. W każdym sprincie powstaje działający kawałek produktu, który zespół omawia z interesariuszami na przeglądzie, a potem poprawia plan na kolejny cykl. Poniżej wyjaśniamy role, zdarzenia i artefakty Scruma, podajemy limity czasu z Przewodnika i porównujemy Scrum z Kanbanem w tabeli. Opisujemy też, jak Scrum wygląda w polskim zespole IT i co zmienia w nim sztuczna inteligencja.

Co to jest Scrum w prostych słowach

Co to jest Scrum, najłatwiej wyjaśnić na przykładzie. Zespół buduje aplikację do rezerwacji wizyt. Na start wybiera najważniejszy kawałek, na przykład logowanie i kalendarz, i w dwa tygodnie doprowadza go do stanu, w którym da się go pokazać użytkownikom. Potem sprawdza reakcje i decyduje, co robić dalej.

W polskich ogłoszeniach o pracę i na uczelniach mówi się o “metodyce Scrum” albo “metodologii Scrum”. Przewodnik używa określenia “ramy postępowania” (po angielsku framework). Opisuje tylko minimum: trzy zakresy odpowiedzialności, pięć zdarzeń i trzy artefakty. Narzędzia, techniki szacowania i sposób prowadzenia tablicy zespół dobiera sam.

Scrum powstał w latach 90. w branży oprogramowania. Schwaber i Sutherland po raz pierwszy przedstawili go publicznie na konferencji OOPSLA w 1995 roku. Wersja z 2020 roku celowo usunęła słowa kojarzone wyłącznie z IT, takie jak “testowanie” czy “system”, bo Scrum stosują dziś także zespoły marketingu, badań i administracji.

Scrum a Agile: jaka jest różnica

Agile to zbiór wartości i zasad spisanych w 2001 roku w Manifeście programowania zwinnego. Manifest mówi na przykład, że ludzie i interakcje są ważniejsze od procesów i narzędzi, a reagowanie na zmiany ważniejsze od realizacji założonego planu. Pod manifestem podpisali się między innymi Schwaber i Sutherland.

Scrum jest jednym ze sposobów wcielenia tych wartości w codzienną pracę. Agile mówi, co cenić. Scrum podaje konkretne reguły: kto podejmuje decyzje, jak długo trwa cykl i jakie spotkania się w nim odbywają. Obok Scruma żyją inne podejścia zwinne, na przykład Kanban i Extreme Programming (XP).

Na czym opiera się Scrum: empiryzm, lean, trzy filary i pięć wartości

Fundamentem Scruma są empiryzm i koncepcja lean. Empiryzm oznacza, że wiedza bierze się z doświadczenia, a decyzje zapadają na podstawie tego, co da się zaobserwować. Lean ogranicza straty i skupia pracę na tym, co najważniejsze. Przewodnik opiera to na trzech filarach: przejrzystości, inspekcji i adaptacji. Praca musi być widoczna, regularnie sprawdzana i korygowana od razu, gdy coś idzie w złą stronę.

Do tego dochodzi pięć wartości: zaangażowanie, skupienie, otwartość, szacunek i odwaga. W praktyce każda z nich przekłada się na konkretne zachowanie. Odwaga to na przykład powiedzenie na przeglądzie sprintu, że funkcja nie jest skończona, choć łatwiej byłoby ją pokazać na zrzutach ekranu.

Role w Scrumie: Scrum Master, Product Owner i Developerzy

Scrum Team to niewielki zespół bez podzespołów i bez hierarchii. Składa się z jednego Scrum Mastera, jednego Product Ownera i Developerów. Przewodnik z 2020 roku nazywa ich zadania zakresami odpowiedzialności. Wycofał też pojęcie “Zespołu Deweloperskiego”, które wciąż można spotkać w starszych materiałach.

Zespół jest interdyscyplinarny, czyli ma wszystkie umiejętności potrzebne do zrobienia przyrostu produktu w jednym sprincie. Jest też samozarządzający: sam decyduje, kto, kiedy i jak wykona zadanie.

Scrum Master: co to za rola

Scrum Master odpowiada za to, żeby zespół stosował Scrum tak, jak opisuje go Przewodnik, i za efektywność całego zespołu. Pomaga Developerom usuwać przeszkody, wspiera Product Ownera w prowadzeniu backlogu i uczy organizację pracy w ten sposób. Przewodnik nazywa Scrum Masterów liderami, którzy działają na rzecz zespołu i organizacji.

Podział zadań zostaje w rękach Developerów. Jeden Scrum Master może wspierać kilka zespołów. W ogłoszeniach o pracę pojawiają się certyfikaty PSM I organizacji Scrum.org i CSM organizacji Scrum Alliance. Certyfikat porządkuje wiedzę, a doświadczenie z prawdziwym zespołem trzeba zdobyć osobno.

Product Owner: jedna osoba, która decyduje o kolejności

Product Owner odpowiada za maksymalizowanie wartości produktu. Formułuje Cel Produktu, opisuje elementy Product Backlogu i ustala ich kolejność. Przewodnik zastrzega, że Product Ownerem jest zawsze jedna osoba. Kto chce coś zmienić w backlogu, musi przekonać Product Ownera.

Tylko Product Owner może przerwać sprint, gdy jego cel przestaje mieć sens. Przykład: zespół buduje integrację z systemem płatności, a firma w połowie sprintu zmienia operatora. Dalsza praca nad starą integracją nie ma wtedy wartości.

Developerzy: wszyscy, którzy budują produkt

Developerzy to wszyscy członkowie zespołu, którzy tworzą przyrost produktu. Programiści, testerzy, projektanci UX i analitycy mają w Scrumie tę samą nazwę. Developerzy przygotowują plan sprintu, pilnują jakości według Definicji Ukończenia i codziennie dostosowują plan do celu sprintu. To oni szacują wielkość zadań, a Product Owner może im w tym pomagać.

Pierwsza Misja AI · Kodożercy

Używasz AI codziennie, ale czy robisz to dobrze?

Kurs Pierwsza Misja AI pokaże Ci techniki promptowania, które naprawdę działają. Praktyczne ćwiczenia na żywym modelu, gamifikacja i certyfikat.

Sprawdź program kursu →

Sprint i zdarzenia w Scrumie

Sprint to cykl o stałej długości, który trwa najwyżej miesiąc. Kolejny sprint zaczyna się od razu po zakończeniu poprzedniego. Wszystkie pozostałe zdarzenia odbywają się wewnątrz sprintu. Przewodnik podaje dla nich maksymalny czas przy sprincie miesięcznym. Przy krótszych sprintach spotkania zwykle trwają krócej.

Jak wygląda sprint w praktyce

Weźmy zespół z dwutygodniowym sprintem. W poniedziałek rano odbywa się planowanie. Product Owner przedstawia najważniejsze elementy backlogu, a cały zespół formułuje Cel Sprintu, na przykład “klient może zapłacić za wizytę kartą”. Developerzy wybierają zadania i dzielą je na części, które da się skończyć w jeden dzień.

Przez kolejne dni zespół pracuje i codziennie spotyka się na 15 minut. W drugi czwartek pokazuje działającą płatność na przeglądzie sprintu. W piątek robi retrospektywę i od poniedziałku zaczyna następny sprint. W trakcie sprintu nie wprowadza się zmian, które zagrażają celowi, a jakość nie może spadać. Zakres można natomiast doprecyzować z Product Ownerem.

Daily Scrum: 15 minut dla Developerów

Daily Scrum to spotkanie Developerów, na którym sami planują swój najbliższy dzień. Odbywa się codziennie o tej samej porze i w tym samym miejscu. Przewodnik z 2017 roku podpowiadał trzy pytania: co zrobiłem wczoraj, co zrobię dziś i co mi przeszkadza. Wersja z 2020 roku je usunęła. Developerzy mogą prowadzić spotkanie, jak chcą, byle dotyczyło postępu wobec Celu Sprintu i kończyło się planem na kolejny dzień.

Artefakty Scruma i zobowiązania

Artefakty to elementy, które pokazują pracę albo wartość tak, żeby wszyscy widzieli to samo. Wersja Przewodnika z 2020 roku przypisała każdemu artefaktowi zobowiązanie, czyli punkt odniesienia do mierzenia postępu.

Definicja Ukończenia (Definition of Done) to formalny opis stanu, w którym praca spełnia wymagania jakości. Zadanie, które jej nie spełnia, nie może trafić do przyrostu ani nawet zostać pokazane na przeglądzie. W zespole webowym taka lista może wyglądać tak: kod przeszedł przegląd, testy automatyczne są zielone, zmiana działa na środowisku testowym, a dokumentacja jest uzupełniona. Zespoły, które mają automatyczny proces CI/CD, sprawdzają dużą część takiej listy bez udziału człowieka.

Refinement, czyli doskonalenie backlogu, to w Przewodniku ciągła praca, poza listą pięciu zdarzeń: dzielenie elementów na mniejsze, dopisywanie szczegółów i szacowanie. Starsze materiały nazywają to “groomingiem”.

Scrum vs Kanban: różnice w tabeli

Kanban to strategia optymalizacji przepływu pracy, opisana w Kanban Guide (wersja z maja 2025 roku). Opiera się na trzech praktykach: zdefiniowaniu i wizualizacji przepływu, aktywnym zarządzaniu zadaniami w przepływie oraz jego doskonaleniu. Kanban Guide nie narzuca ról, iteracji ani spotkań. Wymaga jawnego sposobu kontrolowania liczby zadań w toku i śledzenia czterech miar przepływu.

W praktyce wybór zależy od rodzaju pracy. Zespół, który rozwija nową aplikację i co dwa tygodnie pokazuje ją klientowi, dobrze odnajduje się w Scrumie. Zespół wsparcia, który obsługuje zgłoszenia z dnia na dzień, może lepiej odnaleźć się przy tablicy Kanban i limitem pracy w toku. Wiele zespołów łączy oba podejścia. Pracuje w sprintach, a w trakcie sprintu pilnuje przepływu na tablicy z limitami.

Scrum w praktyce polskiego zespołu IT

W polskich firmach tablice prowadzi się na przykład w Jirze albo Azure DevOps, a spotkania zdalne odbywają się w Teams, Google Meet albo na Slacku. Język jest mieszany. Ludzie mówią “planning”, “daily”, “review” i “retro”, choć polski Przewodnik ma dla tych zdarzeń polskie odpowiedniki. Zespół może wybrać dwutygodniowy sprint, który daje czas na skończenie funkcji i nie oddala zbyt mocno informacji zwrotnej.

Najczęstsze kłopoty powtarzają się w wielu zespołach:

• daily zamienia się w raport dla kierownika i trwa pół godziny,
• Product Ownerem jest osoba, która każdą decyzję musi uzgodnić z zarządem,
• Definicja Ukończenia nie obejmuje testów, więc błędy wracają w kolejnym sprincie,
• retrospektywa kończy się listą problemów bez ani jednego zadania na następny sprint,
• zespół ma kilkanaście osób i daily trwa za długo, choć Przewodnik zaleca wtedy podział na mniejsze zespoły.

Dla osoby, która wchodzi do branży, znajomość Scruma to praktyczne minimum. Ogłoszenia dla juniorów regularnie wymieniają pracę w metodykach zwinnych. Więcej o tym, czego dziś szukają pracodawcy, piszemy w tekście o rynku pracy IT w 2026 roku.

Scrum we współpracy z firmą programistyczną

Firma, która zamawia aplikację, często pierwszy raz spotyka Scruma właśnie u wykonawcy. Klient wskazuje wtedy osobę z prawem do decyzji, która pełni rolę Product Ownera albo blisko z nim współpracuje. Na przeglądzie każdego sprintu widzi działający fragment produktu, więc może zmienić priorytety, zanim zespół wyda pieniądze na niepotrzebną funkcję.

Taki sposób pracy lepiej pasuje do umów rozliczanych za czas pracy niż do sztywnej ceny za z góry opisany zakres. Kto chce zrozumieć cały proces po stronie technicznej, znajdzie go w naszym tekście o tym, jak wygląda programowanie aplikacji internetowych.

Scrum a architektura: mikroserwisy i UML

Przewodnik pomija temat architektury, a ta wpływa na to, jak zespoły dzielą się pracą. Przy architekturze mikroserwisów kilka zespołów może rozwijać osobne usługi i wdrażać je niezależnie. Diagramy pomagają z kolei omówić zadanie na refinemencie, zanim ktoś zacznie pisać kod. Podstawy znajdziesz w tekście o tym, jak modelować systemy w UML.

AI w Scrumie: co zmienia się w pracy zespołu

Narzędzia AI piszą dziś szkice kodu, testów i opisów zadań. Jeff Sutherland i Ralph Jocham opisali wpływ AI na Scrum w dokumencie “AI and Scrum” (wersja z 18 stycznia 2026 roku). Jest to dodatek do Scrum Guide Expansion Pack, uzupełnienia Przewodnika z 2020 roku. Ich główna teza: gdy kod powstaje szybciej, wąskim gardłem staje się decyzja, co warto zbudować. Rośnie więc znaczenie Product Ownera.

Autorzy zalecają też zaostrzenie Definicji Ukończenia. Kod napisany z pomocą AI ma przejść te same testy i ten sam przegląd co kod napisany przez człowieka. Odpowiedzialność za przyrost zostaje przy Developerach.

W codziennej pracy AI przydaje się przy kilku konkretnych czynnościach:

• przygotowaniu szkicu elementu backlogu i kryteriów akceptacji, które Product Owner potem poprawia,
• podsumowaniu notatek z retrospektywy albo przeglądu,
• wygenerowaniu przypadków testowych do zadania.

Jedno zastrzeżenie dotyczy danych. Opisy zadań często zawierają informacje o kliencie i jego systemie. Zanim zespół wklei je do publicznego czatu, warto sprawdzić zasady firmy. Piszemy o tym w tekście o wyciekach firmowych danych do narzędzi AI.

{ aplikacje webowe }

Masz pomysł na aplikację? Najpierw go zobacz

Zanim zainwestujesz w pełny system, przygotujemy klikalny prototyp, który pokażesz zespołowi albo klientom. Potem budujemy aplikację webową, która rośnie razem z firmą.

Zobacz, jak pracujemy → Software house, który prowadzi ten blog

Najczęstsze pytania

Ile trwa sprint w Scrumie?

Przewodnik po Scrumie mówi tylko, że sprint trwa najwyżej miesiąc i ma stałą długość. Zespoły mogą wybrać na przykład sprint tygodniowy albo dwutygodniowy. Krótszy sprint oznacza częstszą informację zwrotną i mniejsze ryzyko, że zespół przez tydzień zrobi coś niepotrzebnego.

Czym Scrum Master różni się od kierownika projektu?

Kierownik projektu planuje pracę, przydziela zadania i rozlicza ludzi z terminów. Scrum Master pilnuje, żeby zespół dobrze stosował Scrum, usuwa przeszkody i uczy organizację tego sposobu pracy. O tym, kto wykona zadanie, decydują Developerzy, a o kolejności prac Product Owner.

Jak zostać Scrum Masterem?

Naturalna droga prowadzi przez pracę w zespole scrumowym, na przykład jako tester, analityk albo programista. Do tego dochodzi certyfikat, na przykład PSM I albo CSM. Przed egzaminem warto przeczytać Przewodnik po Scrumie, bo jest krótki i dostępny po polsku za darmo.

Co to jest planning poker?

Planning poker to technika szacowania, w której każdy Developer wybiera kartę z wartością, a wszyscy odkrywają je naraz. Duże rozbieżności otwierają rozmowę o tym, czego ktoś nie wziął pod uwagę. Przewodnik jej nie wymienia, więc jest jedną z opcjonalnych technik, a zespół może szacować w dowolny sposób.

Czy Scrum nadaje się poza IT?

Tak. Przewodnik z 2020 roku celowo usunął odniesienia do IT, bo Scrum stosują badacze, analitycy, zespoły marketingu i inni specjaliści. Warunkiem jest praca nad złożonym problemem, w którym nie da się z góry zaplanować wszystkiego.

Podsumowanie

Scrum to lekkie ramy pracy dla zespołu do około 10 osób, opisane w Przewodniku po Scrumie z 2020 roku. Składa się z trzech zakresów odpowiedzialności (Product Owner, Scrum Master, Developerzy), pięciu zdarzeń z limitami czasu i trzech artefaktów z przypisanymi zobowiązaniami. Sprint trwa najwyżej miesiąc, a w jego trakcie powstaje działający przyrost, który zespół omawia z interesariuszami. Kanban lepiej pasuje do pracy o nieprzewidywalnym rytmie, a Scrum do rozwoju produktu z planem na kilka tygodni. AI przyspiesza pisanie kodu, więc większy ciężar spada na decyzję, co budować, i na Definicję Ukończenia. Kto chce sprawdzić, czy jego zespół naprawdę pracuje w Scrumie, powinien porównać praktykę z tekstem Przewodnika.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.