Sprint Review

[PaweuB]

Sprint Review - spotkanie zespołu Scrum’owego organizowane na koniec każdego sprintu. Spotkanie to jest istotne ze względu na to, że powinno podczas tego spotkania dojść do „prezentacji” produktu, który był w danej iteracji zaplanowany do dostarczenia.

Kolejność spotkania Sprint Review:

• Prezentacja - Jaki jest przyrost produktu w czasie? Czy wykonujemy to co jest zaplanowane?
• Co jest zrobione? - Przeniesienie niekompletnych zadań do Backlogu lub dokończenie zaległości w kolejnej iteracji
• Velocity - Suma zdobytych punktów w iteracji jako wyznacznik „prędkości wytwarzania” featuresów

Sprint review jest więc spotkaniem, które ma na celu dekompozycję zakończonego sprintu oraz ma określić czy założony postęp/dostarczenie produktu zostało spełnione.
Sprint review poprzedza spotkanie Sprint Retrospective.

@adrianzamorski @cameel czy coś by się przydało dodać do powyższego?

[adrianzamorski]

@PaweuB Proponowałbym pomówić o tym w szerszym gronie, w zakresie wszystkich zespołów. Podobnie pozostałe kwestie.

A tak ogólnie to brzmi OK.

[cameel]

• Co jest zrobione? - Przeniesienie niekompletnych zadań do Backlogu lub dokończenie zaległości w kolejnej iteracji

To trzeba doprecyzować.

Trzeba też dodać, że zadania, które mogą zostać jeszcze dokończone tego samego dnia zostawiamy jako zaczęte.

[PaweuB]

• Prezentacja - Jaki jest przyrost produktu w czasie? Czy wykonujemy to co jest zaplanowane?
• Co jest zrobione? - Przeniesienie niekompletnych zadań do Backlogu lub dokończenie zaległości w kolejnej iteracji
• Velocity - Suma zdobytych punktów w iteracji jako wyznacznik „prędkości wytwarzania” features'ów

To trzeba doprecyzować.
Trzeba też dodać, że zadania, które mogą zostać jeszcze dokończone tego samego dnia zostawiamy jako zaczęte.

Zgodnie z naszą dyskusją na retrospekcji, spróbuję doprecyzować poniżej aby nie było wątpliwości.

• Prezentacja - Sprawdzenie, czy zaplanowany przyrost produktu został dostarczony aktualnie kończoną iteracją. Przez prezentacje rozumie się np. opis słowny dostarczonych funkcjonalności.
• Co jest zrobione? - Określenie czy zaplanowane zadania zostały wykonane w 100% (kod zmerge'owany). Zadania o wysokim prawdopodobieństwie ukończenia zostają w aktywnych task'ach oraz są zamykane w momencie kompletacji. Zadania niekompletne przenoszone są do Backlog'a (mogą np. zostać zaplanowane na kolejną iterację zgodnie ze swoim priorytetem).
• Velocity - Suma zdobytych punktów w iteracji jako wyznacznik „prędkości wytwarzania” features'ów.

Czy ktoś chciałby coś dodać?
Proszę o więcej uwag.

[cameel]

kompletacji

?

Backlog'a
features'ów.

Tu nie trzeba apostrofu.

A jeżeli chodzi o stronę merytoryczną to 👍

[PaweuB]

Rozwinę skrót myślowy "Zadania o wysokim prawdopodobieństwie ukończenia zostają w aktywnych task'ach oraz są zamykane w momencie kompletacji" - Wspomniana "kompletacja", to moment w którym dane Story w Pivotalu ma zmieniony Story Status na Finished.

Czyli, tak jak to robimy aktualnie:
Na sprint review pada pytanie: np. "Czy Story: Update library to v1.5 zostanie zakończone?", mamy poniższe możliwości odpowiedzi:

• "Tak" - Story zostawiamy jako aktywne w Current Iteration oraz "kompletujemy/zmieniamy Story Status na Finished" w momencie gdy zostaje zakończona praca developera, przeprowadzone testy, kod zmergeowany.

• "Nie/Nein/nie wiadomo/jest bloker/etc." - dane Story zmienia swój status na Unstarted oraz przechodzi do Backlogu, pozostaje do zaplanowania w kolejnych iteracjach

[rwrzesien]

Velocity - Suma zdobytych punktów w iteracji jako wyznacznik „prędkości wytwarzania” features'ów.

Fajnie byłoby też mieć sposób na sprawdzenie „prędkości wytwarzania” nie-features'ów, bo robimy ich czasami sporo w iteracji.

Poza tym wszystko ok 👍

[cameel]

@PaweuB To warto by to rozwinięcie dodać do opisu.

@rwrzesien Tylko, że w tej metodologii z założenia skupia się na ficzerach widocznych dla klienta a nieficzerowe zadania traktuje jako stały narzut. Tzn. jeżeli nie dostarczasz ficzerów to stoisz w miejscu i nic nie robisz.