Sprint Planning rozpoczyna każdy Sprint. Przy Sprincie trwającym miesiąc, to Wydarzenie zajmuje maksymalnie osiem godzin. Jeśli Sprinty są krótsze, także Sprint Planning proporcjonalnie się skraca. W wydarzeniu bierze udział cały Scrum Team, oraz zaproszeni Interesariusze lub specjaliści z innych zespołów. Szczegółowy przebieg oraz problemy, jakie mogą towarzyszyć planowaniu pracy w nowym Sprincie omówimy w poniższym tekście.
Sprint Planning – omówione zagadnienia:
- Wprowadzenie
- Jaki jest nowy Cel Sprintu?
- Co zostanie zrobione?
- W jaki sposób zostanie to zrobione?
- Rezultaty Sprint Planningu
- Podsumowanie
Wprowadzenie
Sprint Planning jest jednym z Wydarzeń Scruma, o których pisaliśmy w osobnym artykule. Wydarzenie to koncentruje się wokół User Stories umieszczonych na samej górze Backlogu Produktu. Innymi słowy, na tych, które są najbardziej szczegółowo opisane i przeznaczone do wykonania w najbliższym Sprincie.
Rolę moderatora pełni zwykle Scrum Master. Przebieg podręcznikowo przeprowadzonego spotkania można streścić odpowiadając na trzy pytania:
- Jaki jest nowy Cel Sprintu?
- Co zostanie zrobione?
- W jaki sposób zostanie to zrobione?
Przyjrzyjmy się bliżej, co powinny zawierać odpowiedzi na powyższe pytania.
Jaki jest nowy Cel Sprintu?
Rolą Product Ownera jest przedstawienie uczestnikom spotkania Celu oraz składających się na niego zadań do wykonania.
Rozpoczyna on spotkanie od sformułowania Celu Sprintu oraz uzasadnienia, dlaczego jest on wartościowy z punktu widzenia Klienta. Następnie otwiera dyskusję, w której mogą zabrać głos nie tylko członkowie Scrum Team, lecz również Interesariusze.
Podsumowując dyskusję, Product Owner podaje finalne brzmienie Celu Sprintu, do którego osiągnięcia będzie dążył cały Scrum Team oraz upewnia się, czy Cel jest zrozumiały dla wszystkich zainteresowanych osób.
Co zostanie zrobione?
Druga część Sprint Planningu koncentruje się na wyborze User Stories, które zostaną zrealizowane w nowym Sprincie, oraz na dyskusji nad ich uszczegółowieniem.
Jednym z najtrudniejszych zadań podczas Sprint Planningu może okazać się trafna estymacja ilości oraz pracochłonności zadań wybranych do wykonania. Im bardziej doświadczony jest Scrum Team, tym trafniej szacuje pracę możliwą do wykonania w jednym Sprincie. Zespół stosuje bowiem coraz bardziej skutecznie techniki estymacji, o których pisaliśmy tutaj. Aby przyspieszyć dojrzewanie Zespołu, ułatwić oraz ustandaryzować proces estymacji, wiele Scrum Teams stosuje specjalne metody. Są to przede wszystkim Planning Poker oraz Team Estimation Game.
W jaki sposób zostanie to zrobione?
Trzecia, najbardziej techniczna część Sprint Planningu koncentruje się na udzieleniu odpowiedzi na pytanie „W jaki sposób zostanie to zrobione?”. Zespół Developerski proponuje w niej sposoby wykonania zadań wybranych do realizacji w drugiej części spotkania. Nikt oprócz samych Developerów nie powinien narzucać sposobu realizacji zadań od strony technicznej.
Planowanie powinno uwzględniać nie tylko technologię wykonania, ale też przepływ pracy pomiędzy Developerami. Pozwoli to uniknąć zastojów w pracy [bottlenecks], które mogą powodować opóźnienia w realizacji zadań. Tak jak w przypadku sposobów wykonania zadań, również o podziale zadań pomiędzy poszczególnych Developerów decydują oni sami bez zewnętrznej ingerencji.
Zwykle Zespół Developerski koncentruje się tutaj na podziale User Stories na mniejsze zadania. Optymalna długość realizacji zadania to jeden dzień roboczy.
Rezultaty Sprint Planningu
Rezultatem Sprint Planningu jest jasny i jednoznacznie sformułowany Cel Sprintu, a także szczegółowo opisane User Stories wybrane do realizacji z Backlogu Produktu. Wszystkie te elementy składają się na Backlog Sprintu, Któremu poświęciliśmy osobny artykuł.
Podsumowanie
Sprint Planning to Wydarzenie Scrum rozpoczynające każdy Sprint. Scrum Team może na nie zaprosić Interesariuszy i zewnętrznych ekspertów.
Podczas Sprint Planningu zostaje określony Cel nowego Sprintu. Zespół Developerski ustala z Product Ownerem co zostanie zrobione, oraz podejmuje decyzje, w jaki sposób zrealizować zaplanowane zadania.
Rezultatem Sprint Planningu jest Backlog Sprintu, którym posługują się Developerzy wybierając z kolejki codzienne zadania do realizacji.
Poznaj kolejny etap Sprintu czytając nasz najnowszy wpis: Sprint ReviewJeśli rozważasz karierę w Scrum lub planujesz wprowadzić tę metodykę do swojej pracy poznaj nasz przewodnik Scrum.
Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?