Co by to było, gdybyście teraz byli na spacerze w pięknej czeskiej przyrodzie, tam, gdzie lubicie? Nagle przed wami pojawiają się dziki z młodymi dzikami. Chrum, chrum. Prawdopodobnie zaczęlibyście biec tak szybko, że zawstydzilibyście niejednego Kenijczyka ważącego 40 kg, którego buty byłyby przystosowane do wytrzymałościowych sprintów. W chwili, gdy już biegniecie w stronę dzików, na pewno nie analizujecie, jak można by ten proces wykonać optymalnie, po prostu biegniecie. Tak samo jest w SCRUMie.
Na tym spotkaniu planowaliśmy najbliższy sprint. Dobry sprint to zaplanowany sprint. Celem każdego sprintu jest uruchomiony program, czyli aplikacja internetowa z działającym linkiem URL, która będzie coś wykonywać. Można powiedzieć, że jest to mały projekt w ramach większego projektu. Na tym spotkaniu powinniśmy ustalić, jak powinien wyglądać uruchomiony program na koniec planowanego sprintu.
Wynikiem planowania jest Sprint Backlog. Jest to podzbiór listy zadań zdefiniowanych w Product Backlog. Wybieracie zadania tak, aby:
Prawdopodobnie pojawią się również zmiany w Product Backlog. Dobrze jest je zapisywać, aby przygotować je na spotkanie Sprint Refinement Meeting.
Cele sprintu są na barkach Product Ownera. To on proponuje cele sprintu, a na końcu zatwierdza ostateczne cele sprintu. SCRUM Master maksymalnie może komentować propozycje Product Ownera z punktu widzenia IT (lub technicznych powodów), w sensie – to jest możliwe, a to nie może zostać zrealizowane.
Marián Knězek