Przewodnik po Scrumie | 28. Sprint w Scrumie

Opublikowany: 2022-06-08

Kilka mniejszych wydarzeń składa się na Sprint w Scrumie. Sprinty z kolei wspólnie tworzą ścieżkę, której celem jest opracowanie i wypuszczenie Produktu. Każdy Sprint ma określony Cel Sprintu oraz Backlog Sprintu utrzymywany przez Zespół Deweloperski.

Czym jest Sprint w Scrum – spis treści:

  1. Sprint w Scrumie – wprowadzenie
  2. Sprint w strukturze Scrum
  3. Sprinty i trzy filary empiryzmu
  4. Przezroczystość
  5. Kontrola
  6. Dostosowanie
  7. Jakie zmiany wprowadzić podczas sprintu?
  8. Sprint w Scrumie – Podsumowanie

Sprint w Scrumie – wprowadzenie

Sprint to największe z wydarzeń w Scrumie, o których pisaliśmy w tym artykule. Sprinty to ciągły cykl od początku do końca pracy nad Produktem. Każda iteracja przybliża zespół do osiągnięcia celu produktu.

Każdy Sprint ma określony Cel Sprintu , aby zapewnić spójność w pracy Zespołu Deweloperskiego. Przybiera formę celu biznesowego i odpowiada na pytanie „Dlaczego?”, „W jakim celu?” lub „Dlaczego?” .

Przepływ pracy Sprintu jest udokumentowany w Backlogu Sprintu, który zawiera listę prac niezbędnych do osiągnięcia Celu Sprintu. Jej szczegółowy opis można znaleźć tutaj.

sprint in scrum

Sprint w strukturze Scrum

Każdy Sprint ma określoną strukturę i obejmuje następujące wydarzenia:

  • Planowanie Sprintu – rozpoczyna się Sprint. Podczas tego wydarzenia Zespół Scrumowy wybiera z Backlogu Produktu zaplanowaną pracę do wykonania w nowym Sprincie
  • Daily Scrum – codzienne wydarzenie, na którym Developerzy planują zadania na dany dzień
  • Przegląd Sprintu – otwarty dla Interesariuszy, odbywa się w ostatnim dniu Sprintu. Jego celem jest podsumowanie Sprintu pod kątem postępów na Produkcie
  • Retrospektywa Sprintu – wydarzenie zamykające Sprint, podczas którego Zespół Scrumowy omawia sposoby pracy i pomysły na usprawnienia

Powtarzanie wydarzeń Sprint sprzyja wdrażaniu dobrych praktyk organizacyjnych. Innymi słowy, Zespół Scrumowy wdraża procedury niezbędne do efektywnego planowania, a podczas pracy zwraca uwagę na problemy, które można omówić na odpowiednich wydarzeniach.

Sprinty i trzy filary empiryzmu

Sprinty sprawiają, że Zespół Scrumowy dzieli pracę nad Produktem na równe odcinki czasowe trwające nie dłużej niż miesiąc. Te stałe ramy wzmacniają trzy filary empiryzmu:

  • przezroczystość
  • kontrola
  • dostosowanie

O trzech filarach empiryzmu i ich roli w Scrumie pisaliśmy bardziej szczegółowo tutaj. Ale dzisiaj przyjrzymy się, jak odnoszą się do Sprintu i jego struktury.

Sprints in Scrum and the three pillars of empiricism

Przezroczystość

Podział pracy na sprinty zwiększa przejrzystość, ponieważ wszystkie zaangażowane osoby mogą uzyskać wymagane informacje o statusie pracy nad produktem w każdym sprincie. Planowanie Sprintu i Przegląd Sprintu, początek i koniec Sprintu, w połączeniu z aktualizacją Backlogu Produktu, zapewniają wszystkim interesariuszom cenny wgląd w aktualny status Produktu.

Kontrola

Dzieląc pracę na Sprinty możliwe jest częste monitorowanie jej postępów. Sprzyja to ciągłej identyfikacji problemów w dwóch kluczowych obszarach. To są:

  • zagadnienia związane z osiągnięciem Celu Produktowego – na początku i na końcu Sprintu, tj. podczas Planowania Sprintu i Przeglądu Sprintu
  • przeszkody w pracy Zespołu Scrumowego – podczas codziennych spotkań i na zakończenie każdego Sprintu, czyli podczas Daily Scrum i Retrospective Sprint

Dostosowanie

Adaptacja jest bardzo ważną częścią pracy Zespołu Scrumowego, ponieważ pozwala rozwiązać problemy zidentyfikowane podczas inspekcji. Podczas każdego Sprintu Codzienny Scrum i Retrospektywa Sprintu zapewniają bezpieczną przestrzeń do rozmowy o tym, jak ulepszyć Zespół Scrumowy. Wdrożenie proponowanych rozwiązań następuje natychmiast lub na początku kolejnego Sprintu.

Planowanie Sprintu i Przegląd Sprintu tworzą bezpieczną przestrzeń do dyskusji o Celach i metodach ich realizacji. Dobry, samozarządzający się Zespół Scrumowy z powodzeniem wymyśla, co i jak wdrożyć w kolejnym Sprincie.

Jakie zmiany wprowadzić podczas sprintu?

Każdy Sprint pozostawia wystarczająco dużo miejsca dla Zespołu Scrumowego na doskonalenie i improwizowanie sposobu, w jaki pracuje. Dlatego określ, co zmienić podczas sprintu. Przewodnik po Scrumach nie zawiera listy takich zmian. Jednak pojęcie empiryzmu dostarcza wskazówek do naśladowania i dostosowywania się do sposobu działania danego Zespołu Scrumowego.

  1. Wszelkie zmiany mogą zagrozić osiągnięciu celu sprintu. Zgodnie z pierwszą zasadą, podczas sprintu nie można np. zmniejszyć liczby zadań w tym sprincie lub znacząco zmienić ich charakterystyki. Sprint jest ściśle powiązany z Celem Sprintu. Dlatego, gdy Cel się zmieni, powinniśmy przerwać Sprint. Jednak rzadko się to zdarza, ponieważ jedynym powodem niepowodzenia Sprintu jest przestarzałość Celu. Pamiętaj, że decyzja o zakończeniu Sprintu należy wyłącznie do Właściciela Produktu.
  2. Jakość pracy nie może być zagrożona. Ta reguła ma na celu zapobieganie sytuacji, w której praca wykonana podczas Sprintu staje się Przyrostem, ponieważ nie spełnia ona definicji Ukończenia. Obniżenie jakości pracy może skutkować pozornym osiągnięciem Celu Sprintu, ale sposób realizacji poszczególnych zadań nie spełnia standardów jakości ustalonych przez organizację lub wymaganych przez Interesariuszy.
  3. Backlog Produktu może stać się szczegółowy. Podczas pracy nad Produktem wzrasta wiedza o nim. Dlatego szczegółowość zadań do wykonania wzrasta naturalnie. Dlatego akceptowalną, a nawet wskazaną zmianą podczas sprintu jest uszczegółowienie Backlogu Produktu.
  4. Zakres prac może zostać doprecyzowany lub renegocjowany. Ta zmiana, podobnie jak poprzednia, wiąże się z rosnącym zrozumieniem charakteru wykonywanej pracy. Zespół Deweloperski może to zrobić w porozumieniu z Właścicielem Produktu. Jednak podstawowym warunkiem jej wprowadzenia jest brak sprzeczności z zasadami 1. i 2.

Sprint w Scrumie – Podsumowanie

Sprint to cykliczne wydarzenie Scrum, które zawiera wszystkie pozostałe. Ma podrzędny cel sprintu oddzielony od celu produktu. Backlog Sprintu różni się od Backlogu Produktu. Charakter Sprintów jest cykliczny. Stała długość Sprintów sprzyja utrzymaniu dobrych praktyk przepływu pracy i pielęgnowaniu trzech filarów empiryzmu. Podczas Sprintu Zespół Scrumowy nie może zmienić swojego Celu. Może jednak udoskonalać Backlog Produktu i wraz ze wzrostem wiedzy udoskonalać i negocjować zakres prac.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Autor: Natalia Jaros

Zobacz wszystkie posty

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu