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:

  1. Wprowadzenie
  2. Velocity rzeczywista i planowana
  3. Trudności i zagrożenia związane z Velocity
  4. 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 in scrum - speed of the development team

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.

Scrum Guide | 34. Prędkość Zespołu Deweloperskiego caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?