Czym jest velocity? Jak się je mierzy? Do czego można je wykorzystywać? Czy porównywanie velocity między zespołami to dobry pomysł? W poniższym artykule znajdziecie odpowiedzi na te i podobne pytania. Zapraszam do lektury.
Velocity – definicja
Velocity jest miarą tego co udało się wykonać zespołowi w danej jednostce czasu. Jest to pojęcie, które odnosi się do tego co zostało wykonane w przeszłości. Jest więc miarą historyczną. Velocity pokazuje nam to co się działo, a nie to co przed nami.
Do określania velocity możemy używać wielu jednostek. Jednym z bardziej popularnych sposobów jeżeli chodzi o Scrum, jest mierzenie postępu ilości zrealizowanych Story Pointów w Sprincie. Mamy więc “rzeczy”, czyli Story Pointy reprezentujące złożoność i czasochłonność elementów Product Backlogu, których realizacja jest zamknięta w jednostce czasu, jaką jest tutaj Sprint. Nie oznacza to jednak, że nie można wykorzystywać do tego innych jednostek. Z powodzeniem można posługiwać się określeniem ilości zadań per Sprint, ilością godzin czy mandays’ami. Velocity jest uzależnione od jednostki, którą wykorzystujemy do estymacji naszej pracy i opisuje prędkość z jaką zespół przekształca elementy Product Backlogu w działający Increment. Velocity jest mierzone od startu do końca Sprintu, który może trwać od tygodnia do miesiąca. Moment, w którym uznajemy jakieś zadanie za zakończone musi być spójne z naszą Definicją Ukończenia (DoD). Dopiero w momencie kiedy PBI (Product Backlog Item) przekroczy magiczną granicę “done” na naszej tablicy kanbanowej możemy liczyć je jako zrealizowane i brać pod uwagę podczas kalkulacji velocity.
Warto wspomnieć, że w Kanbanie analogicznym pojęciem jest Throughput (Przepustowość), które określa liczbę elementów pracy ukończonych w jednostce czasu. Niezależnie od tego czy mówimy o Przepustowości czy o velocity, w obu przypadkach określamy historycznie wykonaną pracę.
Wróćmy jednak do Scrum Teams. Zespoły sprawdzają velocity ze Sprintu na Sprint żeby … no właśnie po co? Velocity często jest wykorzystywane przez zespoły do określenia ich capacity, czyli pojemności, na kolejny Sprint.
Velocity a capacity
Jak wspomniałam wyżej wielkość velocity jest wykorzystywana często do predykcji tego ile jednostek będziemy w stanie wykonać, jako zespół, w kolejnej iteracji, czyli do określenia capacity. Trzeba tutaj być jednak czujnym. Realizacja 15 SP w jednym Sprincie nie oznacza, że w kolejnym zrealizujemy tyle samo zadań czy punktów! Może oczywiście się tak zdarzyć i nasze Sprint velocity może być powtarzalne, jednak nie powinniśmy traktować tego jako pewnik. Dlaczego?
Wyobraźmy sobie sytuację w której przebiegamy kilometr w pięć minut. Zawsze kiedy wychodzimy przebiec ten jeden konkretny kilometr koło naszego domu jesteśmy w stanie zrobić to w tym samym czasie. Co się jednak wydarzy kiedy zamiast naszej płaskiej standardowej trasy nagle będziemy wbiegali pod górę? Prawdopodobnie zwolnimy. Nawet jeżeli nie zmienimy trasy, a jedynie warunki atmosferyczne będą inne, może się okazać, że osiągniemy lepszy lub gorszy czas. Wiatr w plecy może być naszym sprzymierzeńcem, a z kolei palące słońce może nas spowolnić. Podobnie jest z velocity. Nawet kiedy wiemy, że wspomniane 15 SP jest naszym średnim velocity, wiele innych aspektów może mieć na nie wpływ. A więc nie powinniśmy traktować tej wartości jako stałej.
Osobiście kieruję się podejściem obliczania średniego velocity z trzech ostatnich Sprintów, by określić capacity na kolejny. Dzięki temu jesteśmy w stanie zobaczyć jak wygląda średnia ilość wspomnianych punktów, które jako zespół zrealizowaliśmy w ostatniej iteracji. Średnie velocity nie jest jednak jedyną rzeczą, którą wspólnie z zespołem bierzemy pod uwagę podczas Sprint Planning’u do określenia tego co możemy wziąć do Sprintu, by zrealizować jego Cel.
Co oprócz velocity należy wziąć pod uwagę przy planowaniu pracy:
- Czy ktoś z nas będzie przebywał na konferencji?;
- Czy są jakieś zależności, które mogą wpłynąć na naszą pracę?;
- Jak wygląda kolejny Sprint pod względem dni wolnych i świąt?;
- Czy planowane są jakieś urlopy w zespole?;
- A może są jakieś dodatkowe zajęcia, które będziemy musieli zrealizować jako zespół, a nie są związane z naszym produktem, więc nie znalazły się w Sprint Backlogu?;
- Co z pracą, którą rozpoczęliśmy w poprzednim Sprincie i jej nie zakończyliśmy? Czy nadal jest ona spójna z Celem Sprintu i Celem Produktu?;
- Jak podchodzimy do zadań niezrealizowanych w poprzedniej iteracji?.
To tylko kilka składowych które warto wziąć pod uwagę starając się uzupełnić Sprint Backlog zadaniami na podstawie poprzedniej miary velocity. Planując pracę na kolejny Sprint nie należy skupiać się na samych punktach, one same w sobie nic nie znaczą. W żaden sposób nie reprezentują wartości biznesowej, a jedynie złożoność i czasochłonność PBI. Jak wiemy z Agile Manifesto działające oprogramowanie i zadowolenie klienta to elementy współpracy na którą powinniśmy zwracać szczególną uwagę. Co za tym idzie naszej pracy powinien przyświecać Cel Produktu i na spójny z nim Cel Sprintu.
Podsumowując wyżej opisane miary mamy więc:
- Velocity – dane odnośnie prędkości dostarczania po jednym Sprincie, czy innej jednostce czasu;
- Średnie velocity – wyliczane na podstawie rezultatów z trzech ostatnich Sprintów;
- Capacity – prognoza naszej prędkości na kolejną iterację.
Anty wzorce
Bywa, że velocity jest źle rozumiane, z czym wiąże się kilka antywzorców. Poniżej znajdziecie listę najbardziej popularnych, błędnych interpretacji podejścia do tej miary.
Określanie capacity na kolejny Sprint tylko na podstawie velocity
Do określania capacity na kolejny Sprint można wykorzystywać velocity, można również posługiwać się wspomnianym wyżej średnim velocity. Jednak nigdy ta wartość nie powinna być analizowana w pojedynkę. Warto wziąć pod uwagę czynniki wymienione powyżej i posłużyć się dodatkowymi miarami. Można na przykład skorzystać z Cumulative Flow Diagram, którego użycie polecają pasjonaci Kanbanu. Jednak zawsze, niezależnie od wybranych metod, warto mieć z tyłu głowy empiryzm jako fundament Scruma oraz wartość biznesową jaką chcemy zrealizować w kolejnej iteracji.
Porównywanie ilości velocity między zespołami
Moim zdaniem porównywanie ilości Story Pointów realizowanych przez dwa inne Scrum Teams to totalne nieporozumienie. Już tłumaczę dlaczego. Wyobraźmy sobie sytuację w której rozwijamy aplikację mobilną na dwie platformy. Mamy więc dwa osobne produkty, dwa osobne Incrementy, a więc dwa osobne zespoły. Jeden z nich realizuje średnio 25 Story Pointów w Sprincie, z kolei drugi około 45 SP. Długości Sprintów są takie same. Co nam mówią te liczby? Czy na samej podstawie tych wartości jesteśmy w stanie określić, który zespół jest szybszy? Czy w ogóle zależy nam na określaniu lidera prędkości realizowanej ilości punktów w Sprincie? Same te numerki nic nam nie mówią. Możemy przypuszczać, że zespoły mają przyjętą inną wagę estymacji i co innego dla nich oznacza 5 SP. Być może drugi zespół w tym Sprincie domykał jakieś zadania z poprzedniej iteracji i przez to ich velocity jest nieco wyższe. Pewności jednak nie mamy. Czy zespół drugi jest szybszy niż pierwszy? Z pozoru można by powiedzieć, że tak, ale w praktyce nie wiemy jaka wartość biznesowa została dostarczona. Nie wiemy nawet czy zespoły realizują podobne funkcjonalności. A gdy nawet przyjmiemy, że tak, to na jednej platformie realizacja danego rozwiązania może być łatwiejsza i szybsza niż na drugiej.
Porównywanie zespołów, nawet tych które realizują tożsame z wyglądu produkty, może być krzywdzące. Velocity to tylko cyfry. Nie mówią nam nic o postępach w realizacji Celu Produktu.
Liczenie Story Pointów per członek zespołu
Kolejny popularny anty wzorzec. A być może nawet element sporu wśród niektórych Scrum Masterów. Moim zdaniem obliczanie zrealizowanych Story Pointów per osoba po każdym Sprincie jest niezgodne z duchem zespołowości i pojęciem wspólnej odpowiedzialności za realizację Incrementu. Podobnie jak w zagadnieniu porównywania velocity pomiędzy zespołami tak i tutaj mamy pokusę stwierdzenia, że jeden deweloper jest szybszy od drugiego. Ale to moim zdaniem “mniejszy” problem. Prawdziwym powodem dla którego jestem przeciwna takiemu podejściu jest brak zrozumienia wspólnej odpowiedzialności za realizowany produkt.
Co z tego, że deweloper X realizuje 5 SP w Sprincie, a deweloper Y tylko 2? Czy to znaczy, że Y leżał do góry brzuchem przez cały Sprint? Czy może jeden z nich pomagał temu drugiemu? Tego nie wiemy. Ponownie te cyfry nam nic nie mówią! Co więcej, prawdopodobnie, Product Backlog Item, który jest realizowany przez zespół przechodzi przez cały przepływ pracy w Sprincie (workflow). A więc od pracy deweloperskiej, code review, poprzez weryfikację jakości, aż do zatwierdzenie “pixel perfect” przez UXa. Kto więc zrealizował wspomniane 5 SP? Odpowiedź nasuwa się sama – cały zespół.
Velocity powinno być wyższe ze Sprintu na Sprint
Niejednokrotnie spotkałam się z ogłoszeniem o pracę na stanowisko Scrum Mastera gdzie jednym z jego odpowiedzialności miało być dbanie o to by zespół ciągle podwyższał swoje velocity. Ba! Spotkałam się nawet ze stwierdzeniami, że trzeba dążyć do tego by velocity wzrastało o 10% po każdym Sprincie. Czy to ma jakikolwiek sens? Absolutnie nie. Velocity ma nam pomóc przewidywać przyszłość, jest jednak miarą historyczną, która pokazuje nam tylko liczbę punktów czy zadań. W żadnym wypadku nie daje nam odpowiedzi co działo się w trzecim Sprincie gdzie zrealizowaliśmy 20 SP zamiast “standardowych” 40. Czy ktoś nagle zachorował? Czy może skupiliśmy się na realizacji Celu Sprintu i pojawiły się jakieś dodatkowe aktywności, które powinny znaleźć odzwierciedlenie w naszym Sprint Backlogu, ale nikt tego nie przypilnował?
Velocity to tylko wartość numeryczna. W żaden sposób nie odzwierciedla wartości biznesowej, której realizacja powinna być priorytetem każdego Scrum Teamu. Co więcej, gdy zespołowi zostanie postawiony cel zwiększania liczby realizowanych punktów per Sprint, jego członkowie mogą sztucznie zawyżać estymaty. Każda jedynka może stać się dwójką. Wtedy na koniec zamiast 50 Story Points, zespół faktycznie osiągnie 55 SP, ale jakie to ma wtedy znaczenie?
Po co nam więc velocity?
Z pewnością velocity jest pomocną miarą, jednak kluczem do jej poprawnego wykorzystania jest jej zrozumienie. Ważna jest świadomość tego, że velocity odnosi się do tego co miało już miejsce. Jako historyczna miara pozwala nam określić, ile “czegoś” wykonaliśmy w ostatnim Sprincie. Tym czymś mogą być zadania, Story Pointy, godziny, tak naprawdę cokolwiek. Miarę tę można wykorzystywać jako wsparcie do określania zakresu prac na kolejny Sprint. Jednak nigdy nie powinniśmy brać pod uwagę tylko tej wartości. Nie powinno się, a wręcz nie wolno porównywać velocity per zespół, czy też pomiędzy poszczególnymi członkami zespołu.
Sprawdź nasze ostatnie wpisy:
