Agile i Scrum: 7 różnic i praca testera w sprincie

Czas czytania: 12 minut

Agile i Scrum to nie synonimy. Agile to sposób pracy opisany w Manifeście programowania zwinnego z 2001 roku: cztery wartości i dwanaście zasad. Scrum to jeden z konkretnych sposobów wcielenia tych wartości w życie, lekki framework z trzema odpowiedzialnościami, pięcioma wydarzeniami i trzema artefaktami. Agile mówi, na czym Wam zależy. Scrum mówi, jak zorganizować pracę, żeby to osiągnąć.

W tym przewodniku porównujemy oba pojęcia w tabeli, przechodzimy przez manifest i zasady z perspektywy testera, opisujemy Scrum dokładnie według Scrum Guide 2020 (bez „Demo Meetingu” i bez trzech pytań na Daily) i pokazujemy, jak wygląda dzień pracy testera w dwutygodniowym sprincie. Tekst jest dla testerów, liderów QA i osób, które dopiero wchodzą do zespołu zwinnego.

wartości w Manifeście programowania zwinnego

zasad, które z nich wynikają

3 + 5 + 3

odpowiedzialności, wydarzenia i artefakty Scruma

10 lub mniej

osób w typowym Scrum Teamie według Scrum Guide 2020

Źródło: agilemanifesto.org (2001) i Scrum Guide 2020, odczyt 11.10.2026.

Spis treści

Agile i Scrum: czym jest jedno, a czym drugie?
Agile a Scrum: jakie są różnice?
Co mówi Manifest Agile i skąd się wziął?
Co dwanaście zasad Agile znaczy dla testera?
Jak wygląda Scrum według Scrum Guide 2020?
Jakie mity o Scrumie warto poprawić?
Jak tester pracuje w dwutygodniowym sprincie?
Agile bez Scruma: kiedy Kanban albo XP?
Agile a Waterfall: co zmienia się dla jakości?
Jakie błędy przy wdrażaniu Agile i Scruma widzimy najczęściej?
Pełna lista źródeł

Agile i Scrum: czym jest jedno, a czym drugie?

Agile to nastawienie i zestaw priorytetów: ludzie i rozmowa ważniejsze niż procedura, działające oprogramowanie ważniejsze niż dokumentacja, współpraca z klientem ważniejsza niż spór o umowę, reagowanie na zmiany ważniejsze niż trzymanie się planu. Manifest nie mówi, ile ma trwać iteracja, kto prowadzi spotkania ani jak wygląda tablica zadań. To celowe, bo Manifest programowania zwinnego ma być wspólnym mianownikiem wielu metod, a nie kolejną metodą.

Scrum odpowiada na pytanie „jak”. Według Scrum Guide 2020 Scrum jest lekkim frameworkiem, który pomaga ludziom, zespołom i organizacjom tworzyć wartość przez adaptacyjne rozwiązania złożonych problemów. Słowo „framework” jest tu ważne: Scrum Guide sam zaznacza, że jest celowo niekompletny i nie opisuje technik testowania, estymacji ani narzędzi. Dlatego mówimy o ramach postępowania, a nie o metodyce, która rozpisuje każdy krok. Polska wersja przewodnika jest dostępna jako oficjalne tłumaczenie Scrum Guide 2020.

Najprostszy sprawdzian dla Waszego zespołu: Agile da się praktykować bez Scruma (na przykład w Kanbanie), a wszystkie wydarzenia Scruma da się odprawiać bez odrobiny zwinności. Retrospektywa, po której nic się nie zmienia, to po prostu spotkanie w kalendarzu z ładniejszą nazwą.

Agile a Scrum: jakie są różnice?

Różnice między Agile a Scrumem najłatwiej zobaczyć obok siebie, bo Agile i Scrum odpowiadają na inne pytania. Tabela zestawia siedem cech, o które najczęściej pytają osoby wchodzące do zespołu zwinnego, i pokazuje, gdzie w praktyce szukać odpowiedzi.

Cecha	Agile	Scrum
Czym jest	zestaw wartości i zasad, sposób myślenia o wytwarzaniu oprogramowania	lekki framework z odpowiedzialnościami, wydarzeniami i artefaktami
Dokument źródłowy	Manifest programowania zwinnego, luty 2001, 4 wartości i 12 zasad	Scrum Guide Kena Schwabera i Jeffa Sutherlanda, aktualna wersja z listopada 2020
Poziom ogólności	parasol dla wielu podejść: Scrum, Kanban, Extreme Programming	jedno z tych podejść, najczęściej stosowane w zespołach produktowych
Role	nie definiuje ról	trzy odpowiedzialności: Product Owner, Scrum Master, Developerzy
Rytm pracy	krótkie cykle i częsta informacja zwrotna, bez sztywnej długości	Sprint o stałej długości, maksymalnie miesiąc
Miara postępu	działające oprogramowanie	Increment spełniający Definition of Done
Jak sprawdzić w zespole	czy zmiana wymagań w połowie pracy jest dla Was informacją, a nie katastrofą	czy wszystkie pięć wydarzeń się odbywa i czy artefakty są aktualne oraz przejrzyste

Źródło: Manifest programowania zwinnego (2001), Scrum Guide 2020.

Zauważcie, że w kolumnie Scrum nie ma słowa „tester”. To nie przeoczenie. Scrum Guide 2020 traktuje wszystkich, którzy tworzą Increment, jako Developerów, niezależnie od specjalizacji. Tester w Scrumie jest więc pełnoprawnym Developerem, a odpowiedzialność za jakość spoczywa na całym zespole. To samo mówi sylabus ISTQB Certified Tester Foundation Level 4.0, który opisuje podejście całego zespołu (whole team approach) jako jedną z dobrych praktyk testowania w projektach zwinnych.

Co mówi Manifest Agile i skąd się wziął?

Manifest jest krótki: cztery pary wartości i jedno zdanie, które ustala sposób ich czytania. Autorzy napisali, że w wyniku swojej pracy zaczęli bardziej cenić:

Bardziej cenimy	niż	Co to znaczy dla jakości
Ludzi i interakcje	procesy i narzędzia	rozmowa testera z programistą przed napisaniem kodu daje więcej niż najlepszy formularz zgłoszenia
Działające oprogramowanie	szczegółową dokumentację	dowodem postępu jest przetestowany Increment, a nie kompletny dokument wymagań
Współpracę z klientem	negocjacje umów	kryteria akceptacji ustala się razem z biznesem, zanim powstanie spór, czy coś jest błędem
Reagowanie na zmiany	realizację założonego planu	plan testów jest żywy i zmienia się co sprint, razem z backlogiem

Źródło: Manifest programowania zwinnego, polskie tłumaczenie na agilemanifesto.org.

Kluczowe jest zdanie zamykające: elementy po prawej są wartościowe, ale większą wartość mają te po lewej. Manifest nie każe więc wyrzucać dokumentacji ani planu. Ustala, co wygrywa, gdy trzeba wybierać. W zespołach, które szkolimy, najczęstszym nieporozumieniem jest właśnie czytanie manifestu jako zakazu dokumentowania, a potem zdziwienie, że nikt nie pamięta, dlaczego system działa tak, a nie inaczej.

Ciekawostka

Manifest nie powstał w sali konferencyjnej. Według historii manifestu na agilemanifesto.org 17 osób spotkało się w dniach 11 do 13 lutego 2001 roku w ośrodku narciarskim Snowbird w górach Wasatch w stanie Utah, żeby, cytując autorów, „porozmawiać, pojeździć na nartach, odpocząć i znaleźć wspólny grunt”, a także zjeść. Wśród nich byli przedstawiciele Extreme Programming i Scruma, w tym Ken Schwaber i Jeff Sutherland, późniejsi autorzy Scrum Guide. Jeden z najbardziej wpływowych dokumentów w historii inżynierii oprogramowania jest więc w pewnym sensie notatką z wyjazdu integracyjnego.

Co dwanaście zasad Agile znaczy dla testera?

Dwanaście zasad Manifestu programowania zwinnego rozwija cztery wartości w konkretniejsze wskazówki. Poniżej streszczamy je wiernie według polskiego tłumaczenia i dopisujemy, co każda zasada oznacza w codziennej pracy testera. Ta druga kolumna to nasza interpretacja, nie część manifestu.

Zasada	Treść w skrócie	Co robi tester
1	zadowolenie klienta dzięki wczesnemu i ciągłemu dostarczaniu wartościowego oprogramowania	testuje małe porcje od razu, zamiast czekać na fazę testów
2	gotowość na zmiany wymagań nawet na późnym etapie	utrzymuje regresję, która pozwala przyjąć zmianę bez strachu
3	częste dostarczanie działającego oprogramowania, w odstępach tygodni, a nie miesięcy	pilnuje, żeby każdy Increment był naprawdę gotowy do wydania
4	codzienna, ścisła współpraca biznesu i zespołu deweloperskiego	dopytuje o kryteria akceptacji, zanim powstanie kod
5	projekty budowane wokół zmotywowanych ludzi, ze wsparciem i zaufaniem	zgłasza blokery od razu, zamiast tłumaczyć się w raporcie
6	rozmowa twarzą w twarz jako najskuteczniejszy sposób przekazywania informacji	wyjaśnia niejasne zgłoszenie rozmową, a nie dziesiątym komentarzem
7	działające oprogramowanie jako podstawowa miara postępu	raportuje, co działa i z jakim ryzykiem, a nie tylko liczbę przypadków testowych
8	zrównoważone tempo, które da się utrzymać bez końca	nie zgadza się na testowanie wszystkiego w ostatni dzień sprintu
9	ciągła dbałość o techniczną doskonałość i dobry projekt	rozwija automatyzację i testowalność, nie tylko wykonanie testów
10	prostota, czyli sztuka maksymalizacji pracy, której nie trzeba wykonać	usuwa testy, które nic nie sprawdzają, zamiast dokładać kolejne
11	najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach	współdecyduje o tym, jak zespół zapewnia jakość
12	regularna refleksja zespołu i dostosowanie działań	przynosi na retrospektywę dane: wyciekłe błędy, czas regresji, niestabilne testy

Źródło: Założenia Manifestu Programowania Zwinnego, agilemanifesto.org (polskie tłumaczenie); kolumna trzecia: opracowanie Quality Island.

Jak wygląda Scrum według Scrum Guide 2020?

Według Scrum Guide 2020 Scrum Team liczy zwykle 10 lub mniej osób i składa się z jednego Product Ownera, jednego Scrum Mastera oraz Developerów. Wersja z 2020 roku zastąpiła słowo „role” słowem „odpowiedzialności” (accountabilities) i zrezygnowała z pojęcia „Zespół Deweloperski” na rzecz jednego Scrum Teamu bez podzespołów i hierarchii.

Product Owner

odpowiada za maksymalizację wartości produktu. Formułuje Cel Produktu (Product Goal), tworzy i porządkuje elementy Product Backlogu. To jedna osoba, nie komitet.

Scrum Master

odpowiada za skuteczność Scrum Teamu: uczy Scruma, usuwa przeszkody, dba o to, żeby wydarzenia się odbywały i mieściły w ramach czasowych. Według przewodnika jest liderem, który służy zespołowi i organizacji.

Developerzy

tworzą każdy użyteczny Increment. Odpowiadają za plan Sprintu (Sprint Backlog), za jakość przez przestrzeganie Definition of Done i za codzienne dostosowanie planu do Celu Sprintu. Tester jest jednym z nich.

Wydarzeń jest pięć i każde ma ramę czasową. Liczby poniżej to maksima podane w Scrum Guide 2020 dla Sprintu trwającego miesiąc. Przy krótszych sprintach wydarzenia są zwykle proporcjonalnie krótsze.

Wydarzenie	Cel według Scrum Guide 2020	Ramy czasowe
Sprint	kontener na wszystkie pozostałe wydarzenia; w nim pomysły zamieniają się w wartość	stała długość, maksymalnie miesiąc
Sprint Planning	ustalenie, dlaczego Sprint jest wartościowy (Cel Sprintu), co można zrobić i jak to zrobić	maksymalnie 8 godzin
Daily Scrum	inspekcja postępu w kierunku Celu Sprintu i dostosowanie Sprint Backlogu; wydarzenie Developerów	15 minut, codziennie o tej samej porze
Sprint Review	inspekcja rezultatu Sprintu z interesariuszami i ustalenie dalszych kroków; sesja robocza, nie prezentacja	maksymalnie 4 godziny
Sprint Retrospective	zaplanowanie sposobów na zwiększenie jakości i skuteczności	maksymalnie 3 godziny

Źródło: Scrum Guide 2020, rozdział Scrum Events.

Trzy artefakty mają w wersji 2020 po jednym zobowiązaniu, które nadaje im kierunek. Product Backlog ma Cel Produktu, Sprint Backlog ma Cel Sprintu, a Increment ma Definition of Done. Dla testera to ostatnie zobowiązanie jest najważniejsze: element, który nie spełnia Definition of Done, nie może zostać wydany ani nawet zaprezentowany na Sprint Review i wraca do Product Backlogu.

Jakie mity o Scrumie warto poprawić?

Wiele opisów tematu Agile i Scrum w sieci, także starsza wersja tego artykułu, powiela określenia sprzed 2020 roku albo dopisuje do Scruma spotkania, których w nim nie ma. Oto najczęstsze nieścisłości i to, co mówi aktualny przewodnik.

Popularne twierdzenie	Jak jest według Scrum Guide 2020
Scrum to metodyka	Scrum to lekki framework, celowo niekompletny; techniki dobiera zespół
Refinement to ceremonia Scruma	refinement backlogu to ciągła czynność, a nie jedno z pięciu wydarzeń
Daily to spotkanie statusowe z trzema pytaniami	Daily Scrum służy Developerom do planowania kolejnego dnia pracy w kierunku Celu Sprintu; trzy pytania były przykładem w wersji 2017, wersja 2020 ich nie zawiera
Na koniec sprintu jest Demo Meeting	nie ma takiego wydarzenia; jest Sprint Review, sesja robocza z interesariuszami, której przewodnik każe nie sprowadzać do prezentacji
Zespół Deweloperski wykonuje pracę	od 2020 roku jest jeden Scrum Team, a w nim Developerzy
Scrum Master pilnuje ceremonii	Scrum Master odpowiada za skuteczność zespołu i organizacji, a pilnowanie wydarzeń to tylko jedna z jego usług

Źródło: Scrum Guide 2020 oraz Scrum Guide 2017 do porównania.

Te różnice nie są akademickie. Zespół, który traktuje Daily jako raport dla kierownika, rzadko zmienia plan w trakcie sprintu, a zespół, który robi „demo” zamiast Sprint Review, nie zbiera od interesariuszy informacji, co dalej. Szczegółowy opis testowania w każdym z pięciu wydarzeń znajdziecie w artykule testowanie w Scrumie według Scrum Guide 2020.

Jak tester pracuje w dwutygodniowym sprincie?

Agile i Scrum wyglądają dobrze na slajdzie, więc zejdźmy na poziom kalendarza. Przykład dotyczy zespołu sklepu internetowego, który pracuje w dwutygodniowych sprintach (10 dni roboczych). Historyjka brzmi: „Jako klient chcę zapisać koszyk na później, żeby wrócić do zakupów na innym urządzeniu”.

Kiedy	Co robi tester	Co powstaje
Refinement przed sprintem	dopytuje: co z produktem, który w międzyczasie się wyprzedał, czy koszyk gościa też się zapisuje, ile dni koszyk żyje	kryteria akceptacji w formie przykładów, lista otwartych pytań do Product Ownera
Dzień 1, Sprint Planning	pomaga oszacować pracę razem z testami i wskazuje ryzyka, które wymagają danych testowych	zadania testowe w Sprint Backlogu, a nie osobna „faza testów” na końcu
Dni 2 do 4	pisze scenariusze z przykładów, przygotowuje dane, testuje API zapisu koszyka, gdy tylko jest gotowe	pierwsze testy automatyczne na poziomie API, zgłoszenia błędów w tym samym dniu
Dni 5 do 8	testuje interfejs na dwóch urządzeniach, test eksploracyjny scenariuszy brzegowych, regresja koszyka i płatności	potwierdzone poprawki, rozszerzona regresja automatyczna
Dzień 9	sprawdza, czy historyjka spełnia Definition of Done, a nie tylko kryteria akceptacji	decyzja: element gotowy albo wraca do Product Backlogu
Dzień 10, Review i Retrospektywa	na Review pokazuje ryzyka, na Retrospektywie przynosi dane: ile błędów znaleziono przed scaleniem kodu, ile po	jedna konkretna zmiana procesu na kolejny sprint

Przykład ilustracyjny, opracowanie Quality Island.

Definition of Done to miejsce, w którym jakość przestaje być dobrą wolą i staje się regułą. Przykład dla takiego zespołu może wyglądać tak:

Przykładowa Definition of Done

01 Kod przeszedł code review i jest scalony z główną gałęzią.

02 Kryteria akceptacji mają testy, a testy automatyczne przechodzą w pipeline CI.

03 Regresja ścieżek krytycznych (logowanie, koszyk, płatność) przeszła bez błędów krytycznych.

04 Nie ma otwartych błędów o priorytecie krytycznym ani wysokim dla tego elementu.

05 Zmiana jest opisana w notatce do wydania i może trafić na produkcję bez dodatkowej pracy.

Zwróćcie uwagę na różnicę między kryteriami akceptacji a Definition of Done. Kryteria dotyczą jednej historyjki i odpowiadają na pytanie „czy robi to, czego chce biznes”. Definition of Done dotyczy każdego elementu i odpowiada na pytanie „czy to jest jakość, którą możemy wydać”. Jeśli Wasz zespół myli te dwie rzeczy, to dobry temat na najbliższą retrospektywę. Tę samą logikę przesuwania testów na początek pracy rozwijamy w tekście o shift left testing, a o tym, jak wdrożyć QA w zespole agile bez spowalniania developmentu, piszą nasi koledzy ze Strefy QA.

Agile bez Scruma: kiedy Kanban albo XP?

Scrum jest najpopularniejszym sposobem pracy zwinnej, ale nie jedynym i nie zawsze najlepszym. Gdy praca przychodzi nieregularnie i nie da się jej sensownie zaplanować na dwa tygodnie, lepiej sprawdza się przepływ. Kanban Guide opisuje Kanban jako strategię optymalizacji przepływu wartości z trzema praktykami działającymi razem: zdefiniowaniem i wizualizacją przepływu pracy, aktywnym zarządzaniem elementami w przepływie oraz doskonaleniem przepływu. Extreme Programming kładzie z kolei nacisk na praktyki inżynierskie: programowanie w parach, ciągłą integrację i pisanie testów przed kodem.

Podejście	Kiedy pasuje	Co dla testera
Scrum	rozwój produktu z celem na kilka tygodni do przodu i stałym zespołem	testy wpięte w rytm sprintu i Definition of Done
Kanban	utrzymanie, zespoły wsparcia, praca o nieregularnym napływie zgłoszeń	limit pracy w toku chroni przed stosem „do przetestowania” na końcu tablicy
Extreme Programming	zespoły, które chcą podnieść jakość kodu praktykami inżynierskimi	TDD i ciągła integracja przesuwają część testów do programistów, tester skupia się na ryzyku

Źródło: Kanban Guide, extremeprogramming.org, Scrum Guide 2020; dobór zastosowań: opracowanie Quality Island.

Agile a Waterfall: co zmienia się dla jakości?

Agile powstał jako reakcja na model kaskadowy, w którym analiza, projekt, implementacja i testy następują po sobie, a testowanie zaczyna się dopiero po zbudowaniu systemu. Model kaskadowy nie jest zły z definicji: przy stałych, dobrze znanych wymaganiach i projektach z twardym zakresem bywa rozsądny. Dla jakości różnice są jednak bardzo konkretne.

Obszar	Waterfall	Agile
Kiedy zaczyna się testowanie	po zakończeniu implementacji	od pierwszego dnia, razem z doprecyzowaniem wymagań
Koszt zmiany wymagań	rośnie z każdą fazą, bo zmienia się dokumentację, projekt i plan testów	niższy, bo zmiana trafia do backlogu przed kolejnym sprintem
Informacja zwrotna od użytkownika	zwykle po wdrożeniu całości	co sprint, na Sprint Review
Regresja	jedna duża przed wydaniem	ciągła, najczęściej zautomatyzowana
Rola testera	osobna faza i często osobny zespół	członek zespołu współodpowiedzialny za Increment

Ostatni wiersz ma konsekwencje dla budżetu. Gdy regresja ma się odbywać co sprint, ręczne powtarzanie setek scenariuszy przestaje się spinać, więc zwinność prawie zawsze idzie w parze z automatyzacją. W naszych projektach to właśnie ten moment, czyli pierwszy sprint, w którym regresja nie mieści się w kalendarzu, najczęściej skłania zespoły do rozmowy o automatyzacji testów. Więcej o tym, jak skrócić regresję, przeczytacie w artykule o testach regresyjnych.

Jakie błędy przy wdrażaniu Agile i Scruma widzimy najczęściej?

Agile i Scrum łatwo ogłosić, a trudno utrzymać. Poniższe wzorce widzimy w firmach regularnie, niezależnie od branży i wielkości zespołu.

Scrum z nazwy

sprinty i tablica są, ale zakres i termin ustalono na rok do przodu, a zmiana wymaga aneksu. To Waterfall w przebraniu.

Mini kaskada w sprincie

programiści kodują do przedostatniego dnia, tester dostaje wszystko na końcu. Sprint kończy się niedokończonymi elementami albo cichym obniżeniem Definition of Done.

Product Owner bez decyzyjności

backlog porządkuje osoba, która każdą decyzję musi uzgodnić z komitetem. Zespół czeka, a priorytety zmieniają się w trakcie sprintu.

Retrospektywa bez zmiany

co dwa tygodnie te same wnioski, żadnego działania w Sprint Backlogu. Po kwartale zespół przestaje mówić prawdę na retro.

Testy poza Definition of Done

element jest „zrobiony”, bo kod jest scalony, a testy „dojdą w następnym sprincie”. Dług jakości rośnie po cichu.

Agile jako zakaz dokumentacji

nikt nie spisuje kryteriów ani decyzji, więc po odejściu jednej osoby nikt nie wie, dlaczego system działa tak, jak działa.

Większość tych problemów nie wymaga nowej metody, tylko powrotu do źródeł: przeczytania Scrum Guide (to kilkanaście stron) i uczciwej odpowiedzi, które jego elementy zespół naprawdę stosuje. Bardzo pomaga też zasada, że jeśli spotkanie nie ma celu, który da się wypowiedzieć w jednym zdaniu, to prawdopodobnie jest tylko spotkaniem. Jeśli chcecie przejść przez to z trenerem, na szkoleniu Metodyki zwinne Scrum i Agile ćwiczymy wydarzenia, artefakty i Definition of Done na przykładach z projektów IT, a osobom odpowiedzialnym za plan i budżet polecamy Agile Project Management w praktyce. Gdy problemem nie jest framework, tylko sam proces jakości w zespole, punktem startu bywa audyt QA.

Co zabrać z tego artykułu

01Agile to cztery wartości i dwanaście zasad z manifestu z 2001 roku. Scrum to lekki framework, który te wartości realizuje: 3 odpowiedzialności, 5 wydarzeń, 3 artefakty.

02Według Scrum Guide 2020 refinement nie jest wydarzeniem, Daily nie jest spotkaniem statusowym z trzema pytaniami, a zamiast „demo” jest Sprint Review jako sesja robocza.

03Tester w Scrumie jest Developerem i współodpowiada za Increment. Jakość zapisuje się w Definition of Done, a nie w dobrej woli zespołu.

04W dobrym sprincie tester pracuje od refinementu: doprecyzowuje kryteria przykładami, testuje API zanim powstanie interfejs i przynosi dane na retrospektywę.

05Zwinność bez automatyzacji regresji szybko się dławi, bo co sprint trzeba ponownie sprawdzić to, co już działało.

Szkolenie Metodyki zwinne Scrum i Agile w Quality Island: Manifest Agile, Scrum według aktualnego przewodnika, wydarzenia, artefakty i Definition of Done na przykładach z projektów IT. Ponad 2 500 przeszkolonych specjalistów, ocena 5.0 z ponad 80 opinii Google.

Zobaczcie program szkolenia