V tomto meetingu sú predbežné User Stories rozdelené na menšie (a tým aj presnejšie špecifikované) User Stories. Takéto menšie User Stories sa už dajú ľahko naimplementovať a ľahko sa dá odhadnúť ich zložitosť. Odhad zložitosti je “na pleciach” SCRUM Mastera a jednotlivých členov jeho tímu.
Na tomto meetingu jednotlivým “drobným” User Stories definujeme prioritu a spôsob, akým sa budú testovať, teda overovať, či robia to, čo zákazník skutočne chcel naimplementovať. Definovať akceptačné kritéria by mal Product Owner.
Ako som už spomínal, nevýhoda SCRUMu je v tom, že User Stories bývajú pomerne málo výrečné, čo môže spôsobiť nejasnosti. Práve tento meeting by mal “rozšifrovať” všetky nejasnosti. Čiže jeden z cieľov tohto meetingu je, aby sme mali dostatok informácií potrebných pre vykonanie jednotlivých úloh. Čo aspekt bezpečnosti alebo vzhľadu jednotlivých User Stories? To všetko by malo byť spresnené do takej miery, ako to bude vyžadovať zákazník pri zisťovaní, či daný User Story spĺňa akceptačné kritéria.
U klasických prístupov k riešeniu projektu je zmena postrachom (horším ako chlapec Denis pre pána Wilsona). V agilných metodikách je zmena prípustná a v celku vítaná. SCRUM ako agilná metodika má zmeny takpovediac “pod palcom”.
Cieľom tohto meetingu je aj naplánovanie väčších zmien. Tieto zmeny sa iniciujú na zvyčajne na podnet Product Ownera. Keďže SCRUM je agilná metodika, zmeny môže iniciovať prakticky hocikto z projektového tímu (aj Team Member).
Malé zmeny, ako napr. zmena písma alebo napr. premenovanie položky v tabuľke, implementujeme do projektu priamo bez zbytočnej byrokracie. Avšak ak zásah do programu môže spôsobiť aj iné dôsledky v inej časti programu, je dobré k zmenám pristupovať s určitou obozretnosťou tak, aby sme nenarušili existujúci koncept projektu (resp. programu). Práve k riešeniu týchto zmien slúži tento meeting.
Výsledkom tohto meetingu je taký Product Backlog, ktorý umožní naplánovanie jednotlivých šprintov.
Marián Knězek