Scrum to metoda, określająca zasady postępowania (ang. framework) dla zespołów, które w zmiennym środowisku wytwarzają złożone produkty. Twórcy intencjonalnie ograniczyli definicję metody do absolutnego minimum tak, by umożliwić wypełnienie frameworku własnym kontekstem, ale też i po to aby zachęcić do szukania własnych rozwiązań.

U podstaw Scruma leży empiryzm, który wpisany jest we wszystkie zdarzenia metody, i który działa na poziomie zarówno produktu, jak i procesu. Aby empiryzm działał, czyli żeby możliwa była inspekcja tego, co udało się osiągnąć i ocena sposobu, w jaki to osiągnięto, niezbędna jest przejrzystość, czyli nieograniczony dostęp do rzeczywistych informacji na temat produktu, procesów, narzędzi, organizacji etc.

Scrum definiuje tylko trzy role: Product Ownera (Właściciela Produktu), Scrum Mastera oraz Zespół Developerski, w skład którego wchodzą nie tylko programiści, ale wszyscy specjaliści niezbędni do tego, by Zespół ten był w stanie samodzielnie wykonać zadania, których się podejmuje. Źródłem wymagań jest Backlog Produktu, w którym Product Owner określa kolejność realizacji tak, by najbardziej efektywnie wykorzystać dostępny czas Developerów.

Praca odbywa się w iteracjach zwanych Sprintami, w czasie których do produktu iteracyjnie dodawane są nowe funkcjonalności. Na początku Sprintu Zespół Developerski dokonuje wraz z Product Ownerem szacunku (ang. forecast), które wymagania zostaną zrealizowane w czasie rozpoczynającej się iteracji i jaki w związku z tym będzie Cel Sprintu, po czym Zespół tworzy własny Backlog Sprintu opisujący listę czynności, które pozwolą osiągnąć ten Cel.

Zespół Developerski każdego dnia omawia postęp prac i dokonuje niezbędnych adaptacji Backlogu Sprintu, pracuje też z Product Ownerem nad doskonaleniem wymagań w Backlogu Produktu doprecyzowując je i dekomponując na elementy dostatecznie małe, by dało się je zrealizować w jednej iteracji. Sprint kończy się prezentacją Przyrostu Produktu, czyli nowej wersji produktu, zawierającej zrealizowane i działające funkcjonalności, po czym Zespół wraz z Product Ownerem i zaproszonymi przez niego interesariuszami lub klientami ocenia to, co udało się osiągnąć i dokonuje niezbędnej adaptacji planów rozwoju produktu.

Przyrost Produktu, a więc produkt w stanie na koniec Sprintu, musi być w stanie pozwalającym na jego wdrożenie (wydanie), jeśli taka będzie decyzja Product Ownera. Aby wszyscy uczestnicy Przeglądu Sprintu tak samo rozumieli co to znaczy, że opisana jakimś wymaganiem funkcjonalność jest ukończona, Zespół w porozumieniu z Product Ownerem określa listę warunków, jakie muszą być spełnione i czynności, jakie muszą zostać wykonane dla ukończonego wymagania. Taka Definicja Ukończenia (ang. Definition of Done) ułatwia też Zespołowi szacowanie pracochłonności wymagań w Backlogu Produktu oraz dyskusję nad szacunkiem w trakcie Planowania Sprintu.

Zespół Developerski kończy Sprint dokonując retrospektywy swych działań i przygotowuje listę usprawnień, jakich dokona w kolejnej iteracji, aby osiągnąć większą efektywność i skuteczniej realizować Cele Sprintu, po czym rozpoczyna się kolejna iteracja (między Sprintami nie ma przerw).

 

Backlog Produktu