Scrum to ramy pracy (ang. framework) dla małych zespołów, które tworzą produkt w warunkach niepewności – gdy całego zakresu nie da się dokładnie zaplanować z góry. Praca jest dzielona na sprinty o stałej długości, po których zespół pokazuje działający fragment produktu, zbiera informację zwrotną i koryguje dalszy plan. W odróżnieniu od kaskadowego podejścia do zarządzania projektami Scrum nie jest metodyką opisującą, jak wykonywać pracę. Określa jedynie minimalny zestaw ról, wydarzeń i artefaktów, które wymuszają regularną inspekcję i adaptację.
Ramy opracowali Ken Schwaber i Jeff Sutherland, którzy przedstawili je po raz pierwszy w 1995 roku. Obowiązującym opisem jest Scrum Guide, ostatnio zaktualizowany w 2020 roku.
Z czego się składa
| Element | Składniki według Scrum Guide 2020 |
|---|---|
| Odpowiedzialności | Product Owner – maksymalizuje wartość produktu i zarządza backlogiem; Scrum Master – odpowiada za skuteczność zespołu i stosowanie Scruma; Developers (deweloperzy) – tworzą przyrost produktu |
| Wydarzenia | sprint, planowanie sprintu, codzienny Scrum (do 15 minut), przegląd sprintu, retrospektywa sprintu |
| Artefakty | backlog produktu (z celem produktu), backlog sprintu (z celem sprintu), przyrost (z definicją ukończenia) |
Sprint trwa najwyżej miesiąc, w praktyce często dwa tygodnie, i zawsze ma tę samą długość, co buduje rytm pracy. W trakcie sprintu nie wprowadza się zmian, które zagrażałyby realizacji celu sprintu, choć zakres prac można doprecyzować z Product Ownerem w miarę zdobywania wiedzy.
Sprint zamyka retrospektywa. Zespół analizuje, co w sposobie współpracy, narzędziach, procesie i definicji ukończenia zadziałało, a co nie, i wybiera najważniejsze usprawnienia – mogą one trafić do backlogu następnego sprintu. To odpowiednik refleksji hansei i zamknięcia cyklu PDCA w Lean.
Przykład
Sześcioosobowy zespół buduje wewnętrzne narzędzie do planowania obsady magazynu. Product Owner – kierownik operacyjny – porządkuje backlog według wartości dla zmian. Sprinty trwają dwa tygodnie. Celem pierwszego jest prognoza zapotrzebowania na kompletujących dla jednej strefy. Na przeglądzie liderzy zmian zgłaszają, że potrzebują wyniku w podziale na godziny, a nie na zmianę, więc wymaganie trafia do backlogu i jest realizowane w kolejnym sprincie. Na retrospektywie zespół ustala, że testy z użytkownikami będą odbywać się w połowie sprintu, a nie dopiero na przeglądzie. Po czterech sprintach narzędzie działa we wszystkich strefach.
Najczęstsze błędy
- Traktowanie sprintów jak etapów harmonogramu kaskadowego, bez działającego przyrostu i bez zmiany planu po przeglądzie.
- Product Owner bez uprawnień do decyzji o priorytetach albo dostępny raz w miesiącu. Zespół buduje wtedy to, co łatwe, a nie to, co najcenniejsze.
- Retrospektywy bez wniosków lub z wnioskami, których nikt nie realizuje. Wybrane usprawnienie powinno mieć właściciela i miejsce w planie kolejnego sprintu.