Estymacje w agile, czyli o story pointach i nie tylko


Estymowanie zadań w zwinnych projektach może przysporzyć wielu problemów. Jak szacować realizację zadań, co do których nie mamy jeszcze koncepcji finalnego rozwiązania? Z pomocą przychodzi wiele technik estymacji w projektach agile. Ważne, aby stosować je rozważnie i zgodnie z faktycznymi potrzebami zespołu.

Jak to zwykle bywa?

Z mojego doświadczenia wynika, że zespoły rzadko wykorzystują pełny potencjał ukryty w zwinnych technikach estymowania zadań. O ile wiedza o najpopularniejszych metodach jest mocno rozpropagowana i powszechnie znana, o tyle samo użycie często odbiega od optymalnego.

W codziennej praktyce nie trudno spotkać zwinny zespół, który działa według schematu:

  • Product Owner przygotowuje kolejność zadań w backlogu wg priorytetów
  • Zespół analizuje zadania z góry backloga, wyjaśniając wszelkie pytania w trakcie tzw. „refinementów”
  • Na kilka dni przed planowaniem lub nawet w jego trakcie, do zadań z góry backloga przypisywane są story pointy, czyli szacunek złożoności, najczęściej wg nieliniowej skali (1, 2, 3, 5, 8, 13 itd.). Popularną techniką estymacji jest „planning poker„, który powstał na bazie tzw. metod Deflickich, czyli technik ankietowych, angażujących grupy eskpertów we wspólne poszukiwanie odpowiedzi na złożone problemy. Po takim spotkaniu zespół ma wspólny obraz przypisanych story pointów, typu:
    • Historia 1 – 3 story pointy
    • Historia 2 – 5 story pointów
    • itd…
  • Zespół określa swoje „velocity na podstawie historycznych danych, czyli wyznacza średnią ilość story pointów, które zrealizował w przeszłości. Na tej podstawie team „wciąga” do sprintu zadania uwzględniając wcześniej przypisane wartości story pointów.
  • W trakcie 2-4 tygodniowego „sprintu” zespół monitoruje realizację historii użytkownika na diagramach zwanych „burn down chart” lub „burn up chart”, wprowadzając ewentualne korekty do planu sprintu.

I to w zasadzie tyle, jeżeli chodzi o estymacje w agile. Czy znasz taki proces ze swojego doświadczenia? Czy przekonuje Cię to co powyżej i chciałbyś tak pracować?

Jak estymować inaczej i do czego używać story pointy

agile estimating and planning, Mike Cohn

Ja również przez długi czas pracowałem w powyżej opisany sposób, aż nie trafiłem na genialną książkę Agile Estimating and Planning, autorstwa Mike’a Cohn’a.

Ta książka otworzyła mi oczy w temacie estymowania projektów w agile. Dzięki niej uzupełniłem braki, które wcześniej nie pozwalały skutecznie szacować pracy w zwinnych projektach.

Lektura tej książki zmieniła również mój światopogląd na temat story pointów i sposobu ich używania.

 

Podstawowy wniosek dotyczący estymacji jest taki, że story pointy nadają się świetnie do szacunków długoterminowych, uśrednionych, kiedy brakuje konkretnych informacji pozwalających planować w inny sposób. Story pointy są jednak obarczone dużym błędem w krótkiej perspektywie czasu („sprintu”), choćby ze względu na:

  • nieliniową skalę (nie można np. oszacować zadania na 4 story pointy)
  • brak uwzględniania chwilowego „velocity” zespołu, wynikającego np. z choroby czy urlopu

Jak inaczej można estymować?

  • Product Owner powinien określić cały zakres projektu, lub przynajmniej pierwszego większego etapu. Najlepiej, aby wypisane zostały wszystkie historie użytkownika. Oczywiście zespół może pomagać w tym zadaniu.
  • Cały zespół, bez wyjątków, powinien przejrzeć tak przygotowany zakres, wyjaśnić wszelkie wątpliwości a następnie przypisać wartości story pointów do każdej z historii
  • Od tego momentu, możliwe jest zarządzanie projektem i opracowywanie „burn down chart”, lub „burn up chart” także dla szacunków całego projektu
  • Przed rozpoczęciem pierwszego sprintu, zespół powinien oszacować swoje „velocity”, na podstawie historycznych, podobnych projektów, lub w przypadku ich braku, na podstawie estymacji czasowych. W tym drugim przypadku cały zespół rozdysponowuje zadania, przypisując je do konkretnych osób, które następnie szacują ich czasochłonność. Jako wynik, otrzymujemy strukturę typu:
    • Historia 1 – przypisanie: Marek, wycena: 2 dni, story pointy: 3
    • Historia 2 – przypisanie: Magda, wycena: 1 dzień, story pointy: 2
    • itd.

    Ćwiczenie to powtarzamy tak długo, aż nie zapełni nam się kalendarz wszystkich osób, uwzględniając ich urlopy oraz zaplanowane zadania w innych projektach. W rezultacie otrzymujemy plan sprintu oraz szacowane „velocity” zespołu (w story pointach).

  • Analogiczny proces powtarzamy przed każdym kolejnym sprintem:
    • Wstępnie „wciągamy” zadania na podstawie story pointów (np. zadania na 30 story pointów, według danych z poprzednich sprintów)
    • Tak wybrane zadania zespół rozdziela miedzy siebie przypisując je do konkretnych osób, które następnie podają szacunki czasowe
    • Weryfikujemy otrzymane estymacje w godzinach/dniach z faktycznymi możliwościami czasowymi zespołu.
    • W razie konieczności wprowadzamy poprawki do planu.

Dlaczego warto łączyć szacunki przy pomocy story pointów i estymacje czasowe?

  • Story pointy nadają się doskonale do szacowania dłuższej perspektywy. Przy odpowiednio długim dystansie prędkość zespołu się uśrednia, uwzględniając urlopy, zwolnienia lekarskie czy też pracę w innych projektach. Dzięki temu uzyskujemy odpowiedzi na pytania typu:
    • Ile zadań o złożoności zbliżonej do konkretnego zadania X, jestem obecnie w stanie zrealizować w czasie 2 tygodni?
    • Jeżeli utrzymam średnią prędkość dostarczania na obecnym poziomie, to kiedy powinienem zakończyć projekt?
    • Jak odejście/dołączenie jednej z osób wpłynęło na naszą prędkość i planowanie projektu?
  • W perspektywie 2-4 tygodniowego sprintu, poleganie tylko na średnich wartościach jest obarczone dużym błędem. Pomyśl o tym choćby w ten sposób – fakt, że ktoś wykorzystuje 26 dni urlopu (czyli nie pracuje średnio trochę ponad 2 dni w miesiącu) nie oznacza, że faktycznie jest nieobecny w takim wymiarze co miesiąc. Jeżeli uwzględnisz wymiar czasu, to dowiesz się:
    • Czy to co założyłeś na podstawie średnich wyliczeń, jest realne w konkretnym okresie czasu?
    • Czy przypisanie zadań jest właściwe?
    • Czy potrzebujesz podjąć konkretne działania natychmiast, aby zwiększyć szanse na osiągnięcie celu sprintu oraz projektu?

Tak jak w życiu codziennym, tak i w estymacjach w agile, prawda leży gdzieś po środku. Potrzebujemy zarówno szacunków w story pointach jak i estymacji czasowych w dniach czy godzinach. Z połączenia tych dwóch podejść powstanie coś, co pozwoli Ci dużo skuteczniej zarządzać zwinnym projektem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *