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.

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

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

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

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?