Sprint w Scrum to wydarzenie-pojemnik, które zawiera w sobie wszystkie pozostałe typy wydarzeń Scrum. Każdy Sprint może być rozumiany jako krótki projekt wyodrębniony z całości pracy nad Produktem. Jako taki, każdy Sprint ma określony Cel Sprintu i prowadzony przez Zespół Developerski Backlog Sprintu.

Sprint w Scrum – omówione zagadnienia:

  1. Wprowadzenie
  2. Struktura Sprintu
  3. Sprint i trzy filary empiryzmu
  4. Jakie zmiany mogą zostać wprowadzone w czasie trwania Sprintu?
  5. Podsumowanie

Wprowadzenie

Sprint to największe z wydarzeń w Scrum, o których pisaliśmy w tym artykule. Sprinty następują po sobie w nieprzerwanym cyklu, który trwa od początku do końca pracy nad Produktem. Zaś każda iteracja przybliża zespół do osiągnięcia Celu Produktu.

Każdy Sprint ma określony Cel Sprintu zapewniający spójność pracy Zespołu Developerów. Ma on formę celu biznesowego i odpowiada na pytanie „Po co?”, „W jakim celu?”, lub „Dlaczego?”.

Przebieg prac w danym Sprincie dokumentuje Backlog Sprintu, zawierający listę prac potrzebnych do realizacji Celu Sprintu. Jego szczegółowy opis znajduje się tutaj.

sprint w scrum

Struktura Sprintu

Każdy ze Sprintów ma określoną strukturę i zawiera w sobie:

  • Sprint Planning – to wydarzenie, od którego rozpoczyna się Sprint. Scrum Team wybiera podczas niego planowane prace z Backlogu Produktu, które są przeznaczone do wykonania w nowym Sprincie
  • Daily Scrum – to codzienne wydarzenie, podczas którego Developerzy planują zadania na dany dzień
  • Sprint Review – to otwarte dla Interesariuszy wydarzenie odbywające się w ostatnim dniu trwania Sprintu. Jego celem jest podsumowanie Sprintu pod kątem postępów w pracy nad Produktem
  • Sprint Retrospective – to wydarzenie kończące Sprint, podczas którego Scrum Team rozmawia o sposobach pracy i pomysłach na jej usprawnienie

Powtarzalność wydarzeń w Sprincie sprzyja wdrażaniu dobrych praktyk organizacyjnych.

Innymi słowy, Scrum Team wdraża się w rutynowe działania niezbędne do efektywnego planowania i podczas pracy zwraca uwagę na problemy, które będą mogły zostać omówione podczas odpowiednich wydarzeń.

Sprint i trzy filary empiryzmu

Dzięki Sprintom Scrum Team zyskuje podział pracy nad Produktem na równe odcinki czasowe trwające nie więcej niż miesiąc. Tak wyznaczone stałe ramy wzmacniają trzy filary empiryzmu:

  • przejrzystość
  • inspekcję
  • adaptację

O trzech filarach empiryzmu i ich roli w Scrum bardziej szczegółowo pisaliśmy tutaj [link]. Poniżej natomiast przyjrzymy się, w jaki sposób znajdują one odzwierciedlenie w Sprincie i jego strukturze.

Sprints in Scrum and the three pillars of empiricism

Przejrzystość

Podział pracy na Sprinty pozwala na wzmocnienie przejrzystości. Dzieje się tak, ponieważ wszystkie zainteresowane osoby mogą w każdym Sprincie otrzymać wymagane informacje na temat stanu pracy nad Produktem.

Sprint Planning oraz Sprint Review, czyli rozpoczęcie i zakończenie Sprintu, łączą się z aktualizacją Backlogu Produktu. Dzięki temu wszyscy zainteresowani zyskują wgląd w bieżący stan prac nad Produktem.

Inspekcja

Dzięki podziałowi pracy na Sprinty możliwe jest częste sprawdzanie postępów w pracy. Sprzyja to regularnemu identyfikowaniu problemów w dwóch kluczowych obszarach. Są to:

  • problemy związane z realizacją Celu Produktu – w momencie rozpoczęcia i zakończenia Sprintu, czyli podczas Sprint Planningu oraz Sprint Review
  • problemy związane ze sposobami pracy Scrum Team – podczas codziennych spotkań oraz na zakończenie każdego Sprintu, czyli podczas Daily Scrum i Sprint Retrospective

Adaptacja

Adaptacja jest bardzo ważną cześcią pracy Scrum Team, ponieważ pozwala na rozwiązywanie problemów zidentyfikowanych podczas inspekcji.

W czasie trwania każdego Sprintu Daily Scrum oraz Sprint Retrospective stwarzają bezpieczną przestrzeń do rozmowy nad poprawą funkcjonowania Scrum Team. Zaproponowane rozwiązania mogą zostać wdrożone od razu bądź od następnego Sprintu. Sprint Planning i Sprint Review stwarzają przestrzeń do dyskusji nad Celami i sposobami realizacji Celu Produktu. Samozarządzający się Scrum Team może podczas tych wydarzeń podjąć decyzję o sposobie realizacji zadań w kolejnym Sprincie.

Jakie zmiany mogą zostać wprowadzone w czasie trwania Sprintu?

Każdy Sprint pozostawia Scrum Team duże pole do doskonalenia sposobów pracy. Dlatego ważne jest określenie, jakie zmiany mogą zostać dokonane w czasie trwania Sprintu. Przewodnik po Scrumie nie zawiera listy takich zmian. Jednak zgodnie z duchem empiryzmu podaje reguły, które można dostosować do sposobu działania konkretnego Scrum Team.

  1. Nie można dokonywać zmian zagrażających osiągnięciu Celu Sprintu. Zgodnie z pierwszą regułą, podczas trwania Sprintu nie można na przykład zmniejszać ilości zadań przewidzianych do wykonania w danym Sprincie lub istotnie zmieniać ich charakterystyki. Sprint jest ściśle związany z Celem Sprintu. Dlatego w momencie zmiany Celu, Sprint powinien zostać przerwany. Taka sytuacja powinna jednak praktycznie się nie zdarzać. Jedynym powodem uzasadniającym przerwanie Sprintu jest bowiem dezaktualizacja Celu. Decyzję o przerwaniu Sprintu może podjąć tylko Product Owner.
  2. Nie można obniżać jakości pracy.Zasada ta ma na celu zapobieganie sytuacji, w której praca wykonana w czasie Sprintu nie może stać się Przyrostem, ponieważ nie spełnia Definicji Ukończenia. Obniżenie jakości pracy może sprawić, że Cel Sprintu zostaje pozornie zrealizowany, jednak sposób wykonania poszczególnych zadań nie spełnia standardów jakościowych określanych przez organizację lub wymaganych przez Interesariuszy.
  3. Można uszczegółowić Backlog Produktu.Podczas pracy nad Produktem wzrasta wiedza na jego temat. W naturalny sposób zwiększa się więc szczegółowość zadań do wykonania. Dlatego zmianą dopuszczalną, a nawet wskazaną w czasie trwania Sprintu jest uszczegółowienie Backlogu Produktu.
  4. Można doprecyzować lub renegocjować zakres prac.Zmiana ta, tak jak poprzednia, wiąże się z coraz lepszym rozumieniem charakteru wykonywanych prac. Może dokonać jej Zespół Developerski w porozumieniu z Product Ownerem. Jednak podstawowym warunkiem jej wprowadzenia jest brak konfliktu z zasadami 1. i 2.

Podsumowanie

Przyrost to gotowa do wydania, świeża wersja Produktu. Obejmuje on wszystkie modyfikacje i ulepszenia wykonane w danym Sprincie zsumowane z dotychczasowym stanem Produktu. Można więc powiedzieć, że Przyrost to najnowsza stabilna, możliwa do wydania wersja Produktu.

W jednym Sprincie może zostać wykonanych kilka Przyrostów. Wszystkie jednak muszą spełniać Definicję Ukończenia.

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 28. Czym jest Sprint w Scrum? caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.