Praca odbywa się w iteracjach zwanych sprintami, które nie mogą być dłuższe niż cztery tygodnie (typowa długość to 2-3 tygodnie), i których długość jest niezmienna. Po każdej iteracji dostarczana jest kolejna wersja tworzonego oprogramowania. Długość sprintu wynosi od 1 do 4 tygodni, a wielkość zespołu to od 5 do 9 osób.

Wszystkie wymagania (oczekiwania) wobec budowanego produktu są przechowywane na specjalnej liście, zwanej backlogiem. Wymagania opisuje się używając takich technik jak przypadki użycia (use cases) lub historyjki użytkownika (user stories). W tym ostatnim przypadku opis dotyczy oczekiwanego zachowania aplikacji z punktu widzenia użytkownika. Kolejność na backlogu odzwierciedla priorytet wymagań.

Zobacz również:

• Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk

Każdy sprint (iteracja) rozpoczyna się od planowania (Sprint Planning). Podczas planowania zespół pobiera kolejno od góry backlogu wymagania do zrealizowania w danym sprincie. Nad każdym z wymagań przeprowadzana jest dyskusja i planuje się szczegółowo jego implementację przygotowując listę czynności, które trzeba wykonać, aby dane zadanie zostało zrealizowane. Zespół dobiera ("bierze na sprint") kolejne wymagania aż do momentu, w którym uzna, że nie może się zobowiązać do zrealizowania więcej niż już zostało przyjęte.

Od tego momentu planowanie jest zamknięte i rozpoczyna się praca nad osiągnięciem celu sprintu - zaimplementowania wszystkich "wziętych na sprint" wymagań (funkcjonalności, poprawienia błędów itp). Zakres sprintu nie może ulec zmianie po zakończeniu planowania.

Podczas trwania sprintu zespół spotyka się codziennie na krótkim spotkaniu - Daily Scrum. Członkowie zespołu odpowiadają na trzy pytania: co robiłem wczoraj?; co zamierzam zrobić dzisiaj? (plan na dziś); jakie problemy utrudniają mi pracę? Podstawowym celem Daily Scrum jest synchronizacja pracy zespołu. Dzięki temu każdy wie, nad czym pracują inni, jakie mają problemy i co będą robić dzisiaj. Ponadto, celem Daily Scrum jest także ujawnianie problemów - wszelkie zgłoszone problemy są notowane na liście Impediments. Scrum Master jest odpowiedzialny za ich jak najszybsze rozwiązanie, tak by zespół mógł nadal wykonywać pracę z maksymalną intensywnością. Co warte podkreślenia, odpowiedzi na trzy pytania Daily Scrum nie są raportem dla przełożonego lub klienta. Scrum Master nie jest przełożonym zespołu, a po pewnym czasie spotkanie to powinno się odbywać bez jego udziału.

Na zakończenie każdego sprintu dostarczana jest kolejna wersja rozwijanego oprogramowania wzbogacona o funkcjonalności, które udało się zbudować w trakcie sprintu. Istotnym założeniem Scruma jest to, że produkt jako całość jest w pełni działający po każdym sprincie, a efektem każdego sprintu jest jedynie dodanie do niego kolejnych funkcji przy zachowaniu założonego poziomu jakości. Poziom jakości definiuje tak zwane kryterium ukończenia (ang. definition of done) - jest to uzgodniony z Product Ownerem zakres kryteriów, które implementacja każdego wymagania musi spełniać, by mogła być uznana za ukończoną. Wymagania, których implementacje nie spełniają kryterium ukończenia, powracają na główny backlog i zespół wraz z Product Ownerem decyduje podczas kolejnego planowania, co z nimi zrobić.

Sprint kończy spotkanie poświęcone jego wynikom - Sprint Review. Ma ono charakter nieformalnego pokazu, podczas którego członkowie zespołu demonstrują Product Ownerowi i wszelkim innym zainteresowanym (najlepiej użytkownikom) wyniki swojej pracy. Następnie, zespół wraz ze Scrum Masterem i Product Ownerem odbywa retrospekcję sprintu - analizę tego, jak przebiegała praca. Jej celem jest wyciągnięcie wniosków i usprawnienie pracy w kolejnym sprincie. Proces następnie się powtarza - odbywa się kolejne planowanie kolejnego sprintu, następnie kolejne 1-4 tygodnie pracy, kolejne wydanie nowej wersji produktu i jej demonstracja, kolejna retrospekcja - i tak dalej.