Sprint Planning

Co to jest sprint planning?

Sprint planning (planowanie sprintu) to ceremonia Scrum która otwiera każdy sprint — typowo 2-tygodniowy cykl pracy zespołu developerskiego. Podczas sprint planning zespół odpowiada na dwa pytania: Co możemy dostarczyć w tym sprincie? (Cel sprintu, wybór elementów z backlogu) oraz Jak to zrobimy? (Rozbicie user stories na zadania techniczne, estymacja). Uczestniczą: Product Owner (odpowiedzialny za backlog i priorytety), Scrum Master (facylitator procesu), Development Team (estymacja i planowanie pracy). Czas trwania: maksymalnie 2 godziny na tydzień sprintu (2-tygodniowy sprint = max 4h sprint planning). Sprint planning kończy się zaakceptowanym Sprint Backlogiem i celem sprintu (Sprint Goal).

Jak wygląda przebieg sprint planning?

Przebieg sprint planning: Część 1 — Co robimy? Product Owner prezentuje priorytety z Product Backlogu. Zespół dyskutuje i wybiera user stories które jest w stanie dostarczyć w sprincie. Kluczowe: zespół sam podejmuje decyzję o pojemności (capacity) — ile story points może dostarczyć bazując na velocity i dostępności. Część 2 — Jak to robimy? Wybrane user stories są rozbijane na konkretne zadania techniczne (tasks). Każde zadanie jest estymowane w godzinach lub story points. Powstaje Sprint Backlog — szczegółowy plan pracy na sprint. Definition of Ready (DoR): user stories do sprint planowania muszą spełniać kryteria gotowości — muszą być zrozumiałe, estymowalne i testowalne. Stories które nie spełniają DoR są odrzucane z planowania.

Jak estymować pracę w sprint planning?

Techniki estymacji: Story Points — względna miara złożoności (nie czasu). Często używa się ciągu Fibonacci: 1, 2, 3, 5, 8, 13, 21. Story 13 to zadanie 13x bardziej złożone niż story 1. Planning Poker — każdy członek zespołu niezależnie wybiera kartę z szacunkiem, następnie wszyscy pokazują jednocześnie. Różnice są dyskutowane do konsensusu. T-shirt sizes (XS, S, M, L, XL) — prostsze podejście dla mniej dojrzałych zespołów. Hours — estymacja w godzinach. Dokładniejsza ale podatna na Parkinson's Law. Velocity — bazowanie na historycznych danych: ile story points zespół dostarczał w ostatnich 3 sprintach? To podstawa do planowania ile wziąć do nowego sprintu. Kluczowa zasada: estymacje są nieprecyzyjne — to narzędzie planowania, nie zobowiązanie.

Jakie są częste problemy w sprint planning?

Problemy w sprint planning: Over-commitment — zespół bierze za dużo do sprintu. Wynik: niedostarczenie sprintu, pressure, tech debt. Fix: bazuj na rzeczywistej velocity, nie aspiracyjnej. Pod-commitment — zespół bierze za mało z ostrożności. Wynik: nieefektywne wykorzystanie pojemności. Fix: stopniowo zwiększaj load gdy jest komfort. Brak Sprint Goal — sprint to tylko lista tasków bez spójnego celu. Wynik: brak priorytetu gdy coś idzie nie tak. Fix: zawsze definiuj jeden zdanie Sprint Goal. Niejakość backlogu — user stories nie spełniają Definition of Ready: brak AC (acceptance criteria), niejasne wymagania. Fix: Product Owner robi 'backlog grooming' przed sprintem. Zmiany w trakcie sprintu — Product Owner dodaje nowe priorytety w trakcie sprintu. Fix: zmiany wchodzą do następnego sprintu, nie bieżącego.

Czym różni się sprint planning od backlog grooming?

Sprint planning vs. backlog grooming (refinement): Backlog Grooming (Refinement) odbywa się w trakcie sprintu — zazwyczaj raz lub dwa razy w tygodniu. Cel: przygotowanie przyszłych user stories na sprint planning. Zespół analizuje, szacuje i rozbija wielkie stories (epiki) na mniejsze. Sprint planning odbywa się na początku sprintu. Cel: wybór które z gotowych stories wchodzą do sprintu i szczegółowe planowanie. Dobra analogia: grooming to gotowanie składników (mise en place), sprint planning to układanie menu na dany dzień. Jeśli grooming nie jest robiony regularnie, sprint planning trwa długo i jest chaotyczny bo zespół musi estymować stories które widzi po raz pierwszy.

Wyślij zapytanie