Przewodnik po Scrumie | 34. Velocity in Scrum – szybkość zespołu programistycznego

Opublikowany: 2022-07-06

Velocity in Scrum pomaga określić tempo, w jakim Zespół Scrumowy wykonuje zadania. Możemy to zdefiniować jako średnią liczbę Story Points zdobytych w jednym Sprincie. Velocity może również oszacować czas trwania projektu na podstawie już ukończonych prac. Ma to jednak sens tylko w przypadku dojrzałego zespołu, który pracuje w równym i stałym tempie. Zobacz, czym jest Velocity i jak sprawić, by działała najlepiej dla Ciebie!

Velocity in Scrum – spis treści:

  1. Velocity w Scrumie – wprowadzenie
  2. Prędkość rzeczywista i planowana
  3. Trudności i zagrożenia związane z Velocity in Scrum
  4. Streszczenie

Velocity w Scrumie – wprowadzenie

Velocity to opcjonalna, ale popularna metoda mierzenia tempa Zespołu Scrumowego. Dzieje się tak, ponieważ dokładnie oszacowana prędkość pozwala w rozsądnym stopniu przewidzieć czas potrzebny na wykonanie projektu. Jest to jednak miara, którą można zastosować tylko do danego Zespołu Deweloperskiego, który będzie wykonywał zadania, które sam sobie „wycenił” za pomocą znanej jednostki, takiej jak np. Story Points.

Prędkość Zespołu Deweloperskiego najczęściej przedstawiana jest w formie Wykresu Prędkości. Na osi X zaznaczone są kolejne Sprinty. Natomiast na osi Y znajdziemy liczbę Story Points lub innych odpowiadających im jednostek, które zostały ukończone w danym Sprincie. Dzięki Wykresowi Prędkości Zespół Scrumowy zyskuje jasny obraz zmian tempa swojej pracy. Jeśli linia zaznaczona na wykresie rośnie, oznacza to, że Zespół optymalizuje swoją efektywność lub zmniejsza wartość Story Points. Zarówno Scrum Master, jak i Product Owner powinni zatem uważnie śledzić linię pokazującą Prędkość Zespołu.

velocity in scrum - speed of the development team

Prędkość rzeczywista i planowana

Rzeczywista Prędkość Zespołu Deweloperskiego opisuje tempo pracy w zakończonym Sprincie i jest obliczana na koniec każdego Sprintu. Pobiera wartość sumy Story Points za wszystkie ukończone User Story. Rzeczywista Prędkość Zespołu Deweloperskiego pozwala zaplanować i oszacować z pewnym prawdopodobieństwem tempo przyszłych zadań.

Z drugiej strony planowana prędkość jest szacowana na podstawie średniej wartości rzeczywistej prędkości. Wymaga założenia braku zmian w Zespole Deweloperskim. Jest to ważne narzędzie wewnętrzne dla Zespołu Deweloperskiego, które na jego podstawie może ocenić, czy współpraca w Zespole układa się dobrze i czy tempo pracy jest utrzymane.

Planned Velocity umożliwia również Właścicielowi Produktu prognozowanie czasu realizacji dobrze zdefiniowanych User Stories, zaplanowanych do realizacji w kolejnych Sprintach. Umożliwia to sprawniejsze pielęgnowanie Backlogu Produktu, o którym pisaliśmy w tym artykule. Jednak praktyka stosowania planowanej prędkości do szacowania czasu trwania projektów nie jest taka prosta.

Trudności i zagrożenia związane z Velocity in Scrum

Prędkość w Scrumie jest często przypisywana zbyt dużą wagę bez uwzględnienia następujących czynników:

  • szacowanie większych całości lub całego projektu – o ile Zespół Deweloperski może dokładnie oszacować liczbę Punktów Story do przypisania do konkretnego zadania, opisanie większych całości do przyszłej realizacji w tych jednostkach jest bardzo trudne lub wręcz niemożliwe
  • zmiany w projekcie – każda zmiana w projekcie potencjalnie oznacza zmianę liczby Punktów Story potrzebnych do osiągnięcia Celu Produktowego. Może się również zdarzyć, że zadania już wykonane będą wymagały modyfikacji lub nawet nie zostaną wykorzystane w ostatecznej wersji Produktu
  • nieprzewidziane zdarzenia – przewidywanie tempa przyszłych projektów na podstawie już zakończonych, czyli przełożenie rzeczywistej prędkości na planowaną prędkość, może skutkować dokładnymi szacunkami. Jednak każdy projekt ma swoje osobliwości i dokładna prognoza oparta na historii jest zwykle niemożliwa.
Velocity in Scrum

Streszczenie

Używanie Velocity jako miary do oceny efektywności Zespołu Deweloperskiego może spowodować pogorszenie jego wiarygodności. Może też pogorszyć jakość szacunków, o czym pisaliśmy bardziej szczegółowo w tym artykule. W końcu, aby uzyskać jak najlepsze wyniki w metrykach, Zespół Deweloperski może przeszacować pracochłonność zadań w celu zwiększenia Prędkości. Jest to szkodliwe, ponieważ sam zespół traci wtedy cenne informacje, aby wprowadzać ulepszenia i dokładniej planować swoje zadania.

Velocity in Scrum przydaje się przede wszystkim jako wewnętrzny miernik wykorzystywany przez Zespół Deweloperski do oceny tempa jego pracy. Dzieje się tak, ponieważ pozwala mu określić, ile zadań jest w stanie wykonać podczas jednego Sprintu.

Prędkość w rękach Product Ownera staje się przydatnym narzędziem do szacowania terminu realizacji większych zadań.

Jednak największe ryzyko wiąże się z wykorzystaniem Velocity jako miernika oceny Zespołu Deweloperskiego. Może bowiem prowadzić do obniżenia jego wiarygodności, a nawet celowego przeszacowania jego wartości w celu poprawy zewnętrznej oceny pracy Zespołu Scrumowego.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Scrum Guide | 34. Velocity in Scrum - Speed of the Development Team caroline becker avatar 1background

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu