Scrum to metoda, określająca zasady postępowania (czasami mówi się też o ramach 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. Schemat rozwoju produktu z wykorzystaniem empiryzmu jest następujący:

  • Na podstawie wiedzy o tym, jaki jest bieżący stan produktu i jakie są związane z nim potrzeby, prognozujemy jakie zmiany i działania przyniosą największą wartość w ciągu krótkiej iteracji.
  • Realizujemy zmiany w produkcie dążąc do wytworzenia rozwiązania nadającego się do użycia.
  • Na koniec iteracji sprawdzamy, czy potwierdziła się prognoza:
    • czy zmiany faktycznie udało się zrobić,
    • a jeśli tak, czy przyniosły oczekiwaną wartość.
  • Na podstawie tej wiedzy i w oparciu o uaktualnioną informację o bieżących potrzebach związanych z produktem, powtarzamy proces.

Dodatkowo, sam produkt ma określoną wizję – wiadomo, czym ma być – z którą związane są kolejne cele, do jakich osiągnięcia dążymy. Kolejne iteracje pozwalają nam się przybliżyć do realizacji aktualnego celu bez konieczności przewidzenia wszystkiego z góry i rozwiązania wszystkich złożonych problemów na raz. W ten sposób empiryzm pozwala rozłożyć budowę na serię niewielkich kroków, z których każdy ma złożoność ograniczoną na tyle, że skutecznie da się kontrolować przebieg procesu.

Empiryczne wytwarzanie produktów jest jednocześnie iteracyjne – kolejne iteracje wyznaczają rytm sprawdzenia i dostosowania produktu – oraz inkrementalne (przyrostowe). Sprawdzając po każdej iteracji jakim produktem dysponujemy aktualnie, możemy skutecznie dostosowywać kierunek dalszego rozwoju, podążając za zmianami potrzeb użytkowników, rynku, technologii itd. Co ważne, wszystkie decyzje podejmowane są w oparciu o to, co wiadomo na pewno. Wszystkie prognozy i plany są często weryfikowane, co jest możliwe dzięki krótkim iteracjom.

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.

Podstawowe informacje

Scrum definiuje trzy odpowiedzialności osób w Zespole: Product Ownera (Właściciela Produktu), Scrum Mastera oraz Developerów. Product Owner odpowiada za określenie, jakie zmiany w produkcie są potrzebne i co jest wartością, jaka dostarczona zostanie interesariuszom i użytkownikom. Developerzy odpowiadają za wytworzenie tej wartości, czyli zbudowanie Przyrostu (nowej wersji produktu), który jest w pełni ukończony i może zostać użyty. Scrum Master odpowiada za efektywność całego Zespołu i zapewnieni, że Scrum używany jest świadomie i poprawnie.

Źródłem pracy dla Developerów jest Backlog Produktu, w którym Product Owner określa kolejność realizacji tak, by najbardziej efektywnie wykorzystać dostępny czas Developerów. Z Backlogiem Produktu związany jest Cel Produktu stanowiący wyjaśnienie powodu, dla którego Backlog ten ma taką a nie inną zawartość i kolejność. Backlog jest więc ciągle zmiennym planem osiągnięcia bieżącego Celu Produktu.

Praca odbywa się w iteracjach zwanych Sprintami, w czasie których do produktu iteracyjnie dodawane są nowe funkcjonalności. Na początku Sprintu Zespół Scrum prognozuje (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 Developerzy tworzą własny Backlog Sprintu opisujący listę czynności, które pozwolą osiągnąć ten Cel. Cel Sprintu określa wartość, jaką iteracja przyniesie interesariuszom.

Developerzy każdego dnia omawiają postęp prac i dokonują niezbędnych adaptacji Backlogu Sprintu, pracują 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 czasie jednej iteracji. Sprint kończy się sprawdzeniem Przyrostu, czyli nowej wersji produktu, zawierającej zrealizowane i działające funkcjonalności. Następnie Zespół Scrum wraz zaproszonymi przez niego interesariuszami lub klientami ocenia to, co udało się osiągnąć i dokonuje niezbędnej adaptacji planów rozwoju produktu.

Przyrost 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 określa listę warunków, jakie muszą być spełnione i czynności, jakie muszą zostać wykonane dla każdego ukończonego wymagania i całego produktu. Taka Definicja Ukończenia (ang. Definition of Done) ułatwia też Zespołowi szacowanie pracochłonności wymagań w Backlogu Produktu oraz dyskusję nad prognozą w trakcie Planowania Sprintu.

Zespół Scrum  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).

Elementy metody

Odpowiedzialności w Zespole Scrum:

Zdarzenia, zapewniające przestrzeń do przeprowadzenia inspekcji stanu spraw i artefaktów:

Artefakty, pozwalające ustalić rzeczywisty stan produktu, procesu i planów:

Ponadto Zespół Scrum dokonuje regularnej Pielęgnacji Backlogu Produktu, która może mieć formę spotkań, ale nie jest zdarzeniem, tylko ciągłym procesem w Scrum.