Agile’owe zespoły żyją lub umierają przez prędkość sprintu. Ale jeśli liczby skaczą z sprintu na sprint, to nie tylko frustrujące — to znak, że coś w procesie nie działa.
Rozłóżmy na czynniki, dlaczego velocity się rozjeżdża i jak to naprawić, zanim rozwali Wam planowanie.
1. Ogólne lub pośpieszne szacowania
Jeśli zespół poświęca 30 sekund na zadanie i rzuca liczbą, nie oczekuj dokładnych sprintów. Bez porządnej rozmowy i konsensusu, story pointy to tylko zgadywanki.
✅ Naprawa: Używaj Planning Pokera, żeby wymusić myślenie i dyskusję. Anonimowe głosowanie i uporządkowane rundy ujawniają nieporozumienia zanim sprint ruszy.
2. Rozrost zakresu w trakcie sprintu
Czy zadania zmieniają się w połowie sprintu? Czy błędy albo dodatkowa praca są wrzucane po cichu?
✅ Naprawa: Ustal sztywne zasady DoD (Definition of Done) i szacuj błędy osobno. Jeśli zajmują dużo czasu, traktuj je jak każde inne zadanie.
3. Zmieniający się skład zespołu
Ktoś poszedł na urlop? Nowy dev w połowie sprintu? Jeśli dostępność zespołu się zmienia, velocity też.
✅ Naprawa: Śledź dostępność zespołu i dostosuj oczekiwaną prędkość — nie bazuj ślepo na starych danych.
4. Niespójne skalowanie zadań
Jeśli “5 punktów” czasem zajmuje pół dnia, a czasem 3 dni — skala jest do kitu.
✅ Naprawa: Ustal wewnętrzne przykłady dla każdego poziomu punktów (np. “Ta historia to 3, bo przypomina nasz task z modalem logowania ze Sprintu 12”).
5. Brak przeglądu historii
Jeśli nie wracacie do poprzednich sprintów, nie ma szans na poprawę.
✅ Naprawa: Na retro sprawdzajcie trafność szacowań. Jeśli zespół ciągle niedoszacowuje 8-punktowców, zmieńcie podejście do ich oceny.
Na koniec
Niestabilne velocity to często efekt niestabilnego planowania. A to najczęściej wynika ze słabych nawyków przy szacowaniu. Przejdź na uporządkowane metody jak Planning Poker i zacznij znów działać przewidywalnie — bez spowalniania.