Podczas tego spotkania wstępne Historie Użytkowników są dzielone na mniejsze (a tym samym dokładniej określone) Historie Użytkowników. Takie mniejsze Historie Użytkowników można już łatwo wdrożyć, a ich złożoność można łatwo oszacować. Oszacowanie złożoności spoczywa „na barkach” SCRUM Mastera i poszczególnych członków jego zespołu.
Na tym spotkaniu określimy priorytet i sposób, w jaki zostaną one przetestowane, czyli zweryfikujemy, czy robią to, co klient naprawdę chciał wdrożyć, za pomocą indywidualnych „małych” User Stories. Właściciel Produktu powinien zdefiniować kryteria akceptacji.
Jak już wspomniałem, wadą SCRUM jest to, że Historie użytkowników są zazwyczaj dość wymowne, co może powodować zamieszanie. To właśnie to spotkanie powinno „rozszyfrować” wszelkie niejasności. Innymi słowy, jednym z celów tego spotkania jest to, abyśmy mieli wystarczającą ilość informacji potrzebnych do realizacji poszczególnych zadań. A co z aspektem bezpieczeństwa lub wyglądem poszczególnych User Stories? Wszystko to powinno zostać doprecyzowane w zakresie wymaganym przez Klienta przy ustalaniu, czy dana Story Użytkownika spełnia kryteria akceptacji.
W przypadku klasycznego podejścia do rozwiązań projektowych zmiana jest strachem (gorszym niż chłopiec Denis dla pana Wilsona). W metodykach zwinnych zmiana jest dopuszczalna i mile widziana. SCRUM jako metodologia zwinna ma zmiany „pod ręką”, że tak powiem.
Celem tego spotkania jest zaplanowanie głównych zmian. Zmiany te inicjowane są zazwyczaj z inicjatywy Właściciela Produktu. Ponieważ SCRUM jest metodologią zwinną, zmiany może inicjować praktycznie każdy z zespołu projektowego (nawet Członek Zespołu).
Drobne zmiany. zmiana czcionki lub np. zmieniając nazwę pozycji w tabeli, wdrażamy ją bezpośrednio w projekcie bez niepotrzebnej biurokracji. Jeśli jednak ingerencja w program może wywołać także inne konsekwencje w innej części programu, warto do zmian podejść z pewną ostrożnością, aby nie zaburzyć dotychczasowej koncepcji projektu (lub programu). To spotkanie służy właśnie rozwiązaniu tych zmian.
Efektem tego spotkania jest Backlog Produktu, który pozwoli na zaplanowanie poszczególnych sprintów.
Marián Knězek