Blog

Scrum Guide | 28. Czym jest Sprint w Scrum?

Sprint w Scrum to wydarzenie-pojemnik, które zawiera w sobie wszystkie pozostałe typy wydarzeń Scrum. Każdy Sprint w Scrum 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 w Scrum 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.

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 w 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.

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 w Scrum 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.

Zapoznaj się z Zobowiązaniami Scrum Team, o których pisaliśmy w naszym artykule.

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

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ść.

Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Recent Posts

7 błędów poznawczych, które wpływają na naszą produktywność

Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…

2 lata ago

Jak obniżyć koszty rekrutacji?

Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…

2 lata ago

Elastyczne plany pracy i milenijni pracownicy

Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…

2 lata ago

Zalety pracy zdalnej dla pracowników i pracodawców

Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…

2 lata ago

O działaniu i biznesowych zastosowaniach voicebotów | AI in business #10

Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…

2 lata ago

Jak wirtualny asystent AI może pomóc w rozwoju Twojej firmy? | AI in business #11

“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…

2 lata ago