W scrumie velocity znaczy tyle co, jaki kawałek product backlogu zespół jest w stanie zrobić w ramach jednej iteracji (jednego sprintu).

Szacunkową wartość velocity możemy otrzymać w oparciu o trakowane statystyki poprzednich sprintów przy założeniu stałości zespołu i tego samego czasu trwania sprintu. Znajomość velocity zespołu jest nie bagatelna, jeśli chodzi o sprint planning w oparciu o tą metrykę produkt owner na jej podstawie wie ile potencjalnie zepół jest w stanie zrobić i jak możemy planować najbliższą iterację.
Dodatkowo widoczna metryka może być dla zespołu czymś w rodzaju motywatora dopingującego do osiągnięcia celu. Jej zalety są duże ponieważ może być używana do zwiększania produktywności zespołu, sprawniejszego usuwania przeszkód stojących przed zespołem, przewidywania czasu trwania releasu, potencjalnego momentu pójścia live z danym releasem lub kilkoma releasami, zarządzania zasobami czy w końcu zwiększania zaangażowania product ownera w budowany produkt.
Stabilna metryka może być wykorzystywana w planowaniu road mapy, dostarcza prognozę wyjścia live danego releasu.Czego natomiast nie można bezwzględnie stosować, to nie można przenosić velocity jednego zepołu na drugi, chociaży przy zachowaniu liczebności osób i czasu trwania sprintu, niewątpliwie metryką będzie różniła się dla różnych projektów np. velocity 5 osoowego zespołu może być lepsza niż velocity zespołu 7 osobowego lub na odwrót. Nawet jeśli produktywność osób jest zbliżona, nigdy nie uda nam sie dojść do tych samych wartości velocity dla obu zespołów, nie w tym rzecz.

Kluczowe punkty które determinują wartości velocity dla zespołów to :

• Złożoność projektu – zespół pracujący nad projektem o dużej złożoności naturnalnie będzie miał gorszą velocity, złożoność projektowa może sie ujawniać w konteksie wymagań jak i wykorzystywanej technologi.
• Rozmiar zespołu scrumowego– metryka jest obliczana dla całego zespołu, z czego wynika naturalna zależność że zespołu większe będą miały większe velocity, będą w stanie w tym samym czasie wykonać więcej.
• Przeszkody – następujące problemy mogą osłabić velocity: wyciąganie członków zespołu do innych zadań, wielozadaniowość, dodawanie i usuwanie ludzi z zespołu w trakcie trwania sprintu, dzielenie zasobów na kilka podprojektów, brak dedykowania zasobów na projekt.
• Brak zangażowania ze strony product ownera – posiadając w projekcie product ownera który pracuje wyłącznie nad jednym projektem, produktem jest dobrą praktyką, cały wysiłek skupiony jest na zespole i doprowadzeniu projektu do założonego celu, dzień po dniu monitorowana ścieżka dojścia do celu.W tym przypadku z pomocą przychodzą burndown charts czyli graficzna reprezentacja velocity zespołu. Wykres wypalenia prezentuje scope jaki pozostał nam osiągięcia celu w ujęciu czasu, pokazuje to co zostało do zrobienia. Velocity wraz z burndown charts pokazują czy zespół realizuje postawione przed nim cele, czy ma na swojej drodze przeszkody które należy niezwłocznie usunąć,aby goal został osiągniety.

Velocity należy mierzyć uważnie z iteracji na iterację, w momencie kiedy mamy stabilną metrykę, możemy mieć względnie stabilny plan releasów, możemy wówczas przewidywać i prognozować przyszłe releasy. Wielu firmom zależy na tym aby z pewnym wyprzedzeniem informować swoich klientów o planowanej road mapie produktu który posiadają, komunikowaniu do klientów planowanych funkcjonalności z wyprzedzeniem. Ma to znaczenie dla postrzegania firmy na zewnątrz jako dobrego partnera który ma solidne zaplecze i dobrze ułożone procesy wewnętrzne.Ma to również znaczenie wewnątrz firmy ponieważ stabilne velocity może wspierać z dużą dokładnością plany zasobów, budżety, planowany zakres projektu.
Aby jednak stwierdzić w opariu o velocity co potencjalnie zespół bedzie w stanie dostaczyć należy poznać zarys scopu, mieć chociażby opisane z grubsza wymagania w postaci ogólnych epiców na poziomie pozwalającym zrozumieć całość prac. Dodatkowo należy brać zawsze pod uwagę wymagania niefuncjonalne, może okazać się że doskonale poradzimy sobie z funkcjonalnościami ale bedą działały wolno lub nie będą spełniały warunków bezpieczeństwa, skalowalności, itp. Wymagania niefuncjonalne choć nie zawsze widoczne na pierwszy rzut oka potrafią skonsumować wiele zasobów i czasu.Ujawnia się w tym momencie właściwe, perspektywicznie utrzymywanie product backlogu, produkt owner mając oszacowany i zpriortyetyzowany backlog, w oparciu o velocity może pokusić się o prognozę daty wykonania produktu, wyekstrachować ilość potrzebnych sprintów.
Dodatkowo czasem warto przyjrzeć się velocity zespołu jako całości i porównać to z velocity poszczególnych członków zespołu, szczególnie w projektach gdzie zespoły są kilku osobowe. Wówczas zobaczymy jak wygląda obłożenie pracą i jak wygląda realizacja, czy w zespole mamy jednego dobrego developera gwiazdę który nie robi dużo czy zespół monolit który dzieli z sobą sukcesy i porażki i pracuje na porównywanym poziomie. Najlepszym synonimem są koła zębate, kręcące sie razem koła zapewniają prawidłowe działanie systemu, jeśli jedno z kół zwolni powoduje zwolnienie całego mechanizmu lub potrzebę aby inne koło kęciło się szybciej i nadraiało, to samo działanie możemy przełożyć na grunt zespołów scrumowych i wytwarzanych przez nie metryk velocity.