Agile / Scrum

Sprint Planning

Ceremonia która uruchamia każdy sprint. Sprint planning odpowiada na dwa pytania: co dostarczymy i jak to zrobimy. Dobrze przeprowadzone = spokojny sprint. Źle = chaos i niedostarczanie.

Max czas (2-tygodniowy)

80-90%

Cel completion rate

Planning Poker

Technika estymacji

PO + SM + Dev

Uczestnicy

Agenda sprint planning

Typowy przebieg sprint planning dla 2-tygodniowego sprintu z 6-8 osobowym teamem.

0-15 min

Sprint Review + Context

Scrum Master przedstawia velocity z ostatnich sprintów. PO omawia cele biznesowe i kontekst dla tego sprintu.

15-45 min

Sprint Goal Definition

Wspólne wypracowanie Sprint Goal — jednego zdania opisującego cel biznesowy sprintu. Musi być mierzalny i wartościowy.

45-90 min

Backlog Selection (Co?)

PO prezentuje priorytety. Zespół wybiera user stories do sprintu bazując na velocity i dostępności. Każda story musi spełniać Definition of Ready.

90-120+ min

Task Breakdown (Jak?)

Wybrane stories są rozbijane na konkretne techniczne tasks. Każdy task estymowany w godzinach. Powstaje Sprint Backlog.

Ostatnie 10 min

Commitment i zamknięcie

Zespół potwierdza commitment do Sprint Goal i Sprint Backlog. Scrum Master dokumentuje. Sprint oficjalnie startuje.

Kluczowe metryki sprintów

Jak mierzyć zdrowie planowania i efektywność zespołu w sprintach.

Velocity

Story points dostarczone per sprint. Bazowa metryka do planowania pojemności.

Target

Stabilna lub rosnąca velocity w ostatnich 3-5 sprintach

Sprint Completion Rate

% story points zacommitowanych które zostały dostarczone w sprincie.

Target

80-90%. Niższy = over-commitment. Wyższy 100% = under-commitment

Carry-over Rate

% stories które nie zostały ukończone i przeniosły się do następnego sprintu.

Target

Poniżej 10-15%. Wysoki carry-over = problemy z estymacją lub scope creep

Sprint Goal Achievement

Czy Sprint Goal został osiągnięty? Binary: tak/nie.

Target

90%+ sprintów z osiągniętym Sprint Goal

Bug Rate per Sprint

Ile bugów odkrytych po sprincie (produkcja lub QA) pochodzi z danego sprintu.

Target

Malejący trend. Wysoki rate = problemy z jakością kodu lub testów

Często zadawane pytania

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.

Czytaj dalej