Velocity pozwala określić tempo, w jakim Scrum Team realizuje zadania. Można zdefiniować ją jako średnią ilość Story Points wykonanych w jednym Sprincie. Velocity może służyć także do szacowania czasu trwania projektu na podstawie już zrealizowanych postępów w pracy. Ma to jednak sens jedynie w przypadku dojrzałego zespołu, który pracuje w równym i stabilnym tempie
Prędkość Zespołu Deweloperskiego – omówione zagadnienia:
- Wprowadzenie
- Velocity rzeczywista i planowana
- Trudności i zagrożenia związane z Velocity
- Podsumowanie
Wprowadzenie
Velocity jest opcjonalnym, lecz chętnie używanym sposobem mierzenia tempa pracy Scrum Team. Dzieje się tak, ponieważ trafnie oszacowana pozwala w pewnym stopniu prognozować czas potrzebny na realizację projektu. Jest to jednak miara, która może być stosowana tylko w odniesieniu do danego Zespołu Developerskiego, który będzie wykonywał zadania, które sam „wycenił” używając znanej sobie jednostki, takiej jak na przykład Story Points.
Prędkość Zespołu Developerskiego jest najczęściej przedstawiana w formie Velocity Chart. Na osi X są tutaj oznaczane kolejne Sprinty. Natomiast na osi Y znajdziemy ilość Story Points lub innych, odpowiadających im jednostek, które zostały zrealizowane w danym Sprincie. Dzięki użyciu Velocity Chart, Scrum Team zyskuje wizualizację zmian w tempie swojej pracy. Jeśli linia oznaczona na wykresie się wznosi, oznacza to, że Zespół optymalizuje swą efektywność lub zmniejsza wartość Story Points. Zarówno Scrum Master jak i Product Owner powinni więc uważnie śledzić przebieg linii ukazującej prędkość Zespołu.
Velocity rzeczywista i planowana
Rzeczywista Velocity Zespołu Developerskiego opisuje tempo pracy w ukończonym Sprincie i jest obliczana na koniec każdego z nich. Przyjmuje ona wartość sumy Story Points dla wszystkich zrealizowanych User Stories. Rzeczywista prędkość Zespołu Developerskiego pozwala na planowanie i szacowanie z pewnym prawdopodobieństwem tempa realizacji przyszłych zadań.
Planowana Velocity jest natomiast szacowana na podstawie uśrednionej wartości rzeczywistej Velocity. Wymaga ona przyjęcia założenia o braku zmian w Zespole Developerskim. Jest ważnym wewnętrznym narzędziem Zespołu Developerskiego, który na jej podstawie może ocenić, czy współpraca w Zespole przebiega właściwie i czy tempo pracy zostaje zachowane.
Velocity planowana pozwala także Product Ownerowi na szacowanie czasu realizacji dobrze zdefiniowanych User Stories przewidzianych do wykonania w kolejnych Sprintach. Dzięki temu możliwa jest sprawniejsza pielęgnacja Backlogu Produktu, o której pisaliśmy w tym artykule. Jednak praktyka stosowania planowanej prędkości do szacowania długości trwania projektów nie jest tak prosta.
Trudności i zagrożenia związane z Velocity
Jest jej często przypisywane zbyt wielkie znaczenie, nie biorąc pod uwagę następujących czynników:
- szacowanie większych całości lub całego projektu– o ile Zespół Developerski jest w stanie trafnie oszacować ilość Story Points, którą należy przypisać konkretnemu zadaniu, opisanie w tych jednostkach większych całości przeznaczonych do przyszłej realizacji jest bardzo trudne lub niemożliwe
- zmiany w projekcie– każda zmiana w projekcie oznacza potencjalnie zmianę ilości Story Points niezbędnych do realizacji Celu Produktu. Może też okazać się, że już wykonane zadania będą wymagały modyfikacji lub nawet nie zostaną wykorzystane w finalnej wersji Produktu
- nieprzewidziane wydarzenia– przewidywanie tempa realizacji przyszłych projektów na podstawie tych już zrealizowanych, czyli przekładanie rzeczywistej Velocity na Planowaną, może owocować trafnymi szacunkami. Jednak każdy projekt ma swoją specyfikę i trafne przewidywanie w oparciu o historię jest zwykle niemożliwe.
Podsumowanie
Użycie Velocity jako metryki służącej do oceny skuteczności Zespołu Developerskiego może powodować, że jej wiarygodność się obniża. Może pogarszać się też jakość estymacji, o których pisaliśmy bardziej szczegółowo w tym artykule [link]. Dążąc do uzyskania jak najlepszych wyników w metrykach, Zespół Developerski może bowiem zawyżać pracochłonność zadań, po to, aby zwiększyć prędkość. Jest to szkodliwe, ponieważ sam zespół traci wtedy cenną informację pozwalającą mu dokonywać usprawnień i dokładniej planować swoje zadania.
Szacunkowa prędkość jest użyteczna przede wszystkim jako wewnętrzna miara stosowana przez Zespół Developerski do oceny tempa własnej pracy. Pozwala bowiem określić, ile zadań jest on w stanie zrealizować w czasie jednego Sprintu.
Velocity w rękach Product Ownera staje się użytecznym narzędziem pozwalającym na szacowanie terminu realizacji większych zadań.
Z największymi zagrożeniami wiąże się jednak używanie jej jako metryki służącej do oceny Zespołu Developerskiego. Może to bowiem prowadzić do obniżenia jej wiarygodności, a nawet celowego zawyżania jej wartości w celu poprawy zewnętrznej oceny pracy Scrum Team.
Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?