Witam.

Dla pewności, że mówimy o tym samym, w zarysie:

Capacity mówi, jaki procent pojemności zespołu zostanie przeznaczony na produkcję z testami, usuwanie błędów, rozwój architektury, na utrzymanie produktów (jeśli zespół też się tym zajmuje) itd.

Velocity natomiast mówi o szybkości pracy zespołu, czyli najczęściej dostarcza informacji, ile Story Points zespół dostarcza co Sprint.

W sytuacji, gdy zespół widzi, że oczekiwany, przez Product Ownera, zakres Sprintu jest większy niż możliwości zespołu, powinien dokonać rewizji Capacity, aby ustalić, czy jest możliwość zwiększenia pojemności zespołu w zakresie produkcji np. na nowe User Stories, kosztem innych obszarów (bug fixing, maintenance etc), bez wygenerowania istotnych ryzyk dla Sprintu / Produktu. Tutaj również warto podjąć dialog z Product Ownerem, przy ewentualnym wsparciu Scrum Mastera, na temat priorytetów ewentualnych błędów do naprawy w stosunku do nowych wymagań – czyli ustalić co jest ważniejsze w danym momencie z perspektywy biznesowej.

Jeśli nie ma możliwości zoptymalizowania Capacity pod kątem oczekiwań Product Ownera, zespół wsparty Scrum Masterem powinien przekazać informację o braku możliwości realizacji oczekiwanego zakresu Product Ownerowi, wraz z realną propozycją podejścia do bieżącego Sprintu.

Sprint Planning zakłada możliwość negocjacji zakresu Sprintu pomiędzy Zespołem Deweloperskim a Product Ownerem. Druga część planowania Sprintu to analiza i planowanie realizacji wymagań przez Zespół Deweloperski, które Product Owner omówił z zespołem w części pierwszej tego zdarzenia. Wynikiem tych analiz i planów często jest informacja zwrotna o możliwości zwiększenia zakresu Sprintu lub o potrzebie jego zmniejszenia.

Podsumowując efektywna i jasna komunikacja, współpraca i zaufanie w zespole, rozwiązują tego typu problemy.

Pozdrawiam.

Łukasz Czopek.