Ogromna większość Zespołów Scrum, a być może wszystkie, poświęcają sporo czasu w ramach pielęgnacji Backlogu Produktu na szacowanie jego elementów. Posługują się przy tym różnymi technikami i przedstawiają wyceny numerycznie, tekstowo lub symbolicznie, albo po prostu dzielą estymowane elementy na różne kategorie.

Co znamienne, poziom zrozumienia najczęściej używanych praktyk jest w najlepszym razie umiarkowany, a im ono niższe, tym silniejsze przekonania panują w Zespołach odnośnie do tego, co w Scrumie jest wymagane i dlaczego.

I tak przekonanie, że story pointy są jedyną dopuszczalną formą szacowania w Agile (a więc i w Scrumie), idzie w parze z zupełnie rozbieżnymi definicjami tego, czym pojedynczy punkt jest: miarą złożoności, czasochłonności, pracochłonności, wielkości rozwiązania, jakie trzeba zbudować, czy jeszcze czegoś innego.

Podobnie rzecz ma się z planning pokerem, który rzekomo ma być wymagany, bo przecież stosuje się w nim „obowiązkowe story pointy” – można zetknąć się z tak absurdalnym sposobem korzystania z tej techniki, że nie wiadomo czy śmiać się, czy płakać.

Co jest naprawdę wymagane w Scrumie

Definicja Scruma, czyli Scrum Guide w ogóle nie wspomina o szacowaniu elementów Backlogu Produktu. Można tam znaleźć jedynie stwierdzenie, że w wyniku jego pielęgnacji do elementów mogą być dodane różne atrybuty, na przykład informacja o wielkości.

To oznacza, że formalnego wymogu szacowania nie ma w Scrumie, nie mówiąc już o wskazaniu konkretnej techniki lub formy, w której ewentualne wyceny byłyby zapisywane. Zespoły Scrum mogą indywidualnie zdecydować, czy szacowania potrzebują i swobodnie wybrać sposób jego przeprowadzenia.

Czy zatem można w Scrumie niczego nie szacować…?

Nie, to niemożliwe. Rozwój produktu w Scrumie nie polega przecież na bezmyślnym realizowaniu kolejnych zleconych przez interesariuszy prac, ale świadomym wybieraniu tego, co przyniesie interesariuszom wartość. Takiej oceny opłacalności nie da się zrobić bez dysponowania dwoma oszacowaniami: spodziewanej wartości i potencjalnych kosztów jej wytworzenia.

Należy też pamiętać, że Scrum opiera się o empiryczną kontrolę procesu, której motorem napędowym są Sprinty. Każdy z nich rozpoczyna się postawieniem hipotezy, że coś jest możliwe do zrealizowania i przyniesie wartość interesariuszom, a kończy się jej sprawdzeniem. Wnioski z tej inspekcji wpływają na działanie Zespołu w Sprincie kolejnym. Wspomniana hipoteza, nazywana prognozą Sprintu (ang. Sprint forecast), nie mogłaby być sporządzona, gdyby Zespół w ogóle nic nie szacował.

Cel determinuje formę i sposób szacowania

Cykl życia większości elementów Backlogu Produktu zaczyna się zwykle na długo przed tym, zanim podjęte zostaną one do realizacji w którymś ze Sprintów. Często na początku są to jedynie ogólne hasła, które dopiero w ramach pielęgnacji Backlogu Produktu zostają doprecyzowane. Częścią tego procesu jest też dyskusja o wartości każdego elementu i wysiłku, jaki wiązał się będzie z jego realizacją.

Zdarza się, że Product Owner uznaje, iż nie warto zajmować się jakimś tematem i usuwa go z Backlogu Produktu. Dużo częściej okazuje się, że problem opisany elementem Backlogu Produktu jest zbyt złożony, by dało się go rozwiązać w czasie jednego Sprintu i konieczna jest jego dekompozycja, czyli podział na kilka mniejszych części.

Szacowanie zarówno wartości, jak i kosztów realizacji, które odbywa się w czasie pielęgnacji Backlogu Produktu, nie może być przesadnie precyzyjne z kilku powodów.

Po pierwsze, na początku za mało wiadomo o tym, co kryje się w elementach nowo dodanych do Backlogu.

Po drugie, oszacowania takie sporządzane są zwykle na dłuższy czas przed faktyczną realizacją poszczególnych elementów Backlogu, więc sporo może się w międzyczasie zmienić, co czyni dążenie do precyzyjnych estymat zwyczajnie nieopłacalnym.

Po trzecie, precyzyjne oszacowania możliwe byłyby wyłącznie wtedy, gdyby było wiadomo, kiedy nastąpi realizacja, jaki będzie stan produktu w tym momencie, jakie będą możliwości Zespołu, jakimi narzędziami będzie dysponował, kto wykonywał będzie pracę itd. Można również i te rzeczy oszacować, ale mizerny (lub żaden) wzrost precyzji takich wycen okupiony zostanie ogromnym wzrostem ich uzyskania.

To przede wszystkim dlatego odradza się Zespołom zwinnym szacowanie w dniach roboczych czy godzinach i zachęca się je do użycia estymat relatywnych, czyli opartych o porównanie lub kategoryzację elementów Backlogu Produktu. Chodzi przecież nie o precyzję oszacowania, ale zgrubną jego wartość wystarczającą do podejmowania decyzji.

A tych decyzji jest wiele. Najpierw jest to podstawowa decyzja Product Ownera, czy umieścić coś w ogóle w Backlogu Produktu. Potem wybór pozycji na liście elementów i ewentualny podział na kilka mniejszych części, możliwych do zrealizowania w czasie krótkiego Sprintu.

Szacowanie jako część pielęgnacji Backlogu Produktu

Z powyższych rozważań płynie kilka wniosków, niekoniecznie oczywistych:

  1. Szacowanie każdego elementu Backlogu Produktu odbywa się zapewne więcej niż raz, w kontekście różnych decyzji, jakie trzeba na bazie tego oszacowania podjąć.
  2. Szacowanie na różnych etapach cyklu życia elementu Backlogu Produktu wymaga różnej precyzji.
  3. Skoro poziom precyzji i cel szacowania są różne, istnieje niewielkie prawdopodobieństwo, że za każdym razem będzie można posłużyć się tą samą techniką i formą oszacowania.

Najczęściej wygląda to tak, że na początku Product Owner pyta Developerów z grubsza o to, czy zrobienie czegoś to praca na parę godzin, dni, tygodni, czy może miesięcy, a interesariuszy o korzyści, jakie przyniesie wprowadzenie zmian w produkcie (lub ewentualne straty, jeśli się tego nie zrobi). I to wystarczy.

Żaden planning poker i story pointy na tym etapie nie są potrzebne. Dopiero potem, przy bardziej detalicznych dyskusjach o poszczególnych elementach Backlogu Produktu, Zespół może, choć nie musi, po nie sięgnąć. Odbywa się to w ramach pielęgnacji Backlogu Produktu, ale ważne jest podkreślenie, że proces ten nie służy wyłącznie oszacowaniu i dokonywaniu ewentualnej dekompozycji elementów.

Celem pielęgnacji jest przygotowanie Zespołu Scrum do Planowania kolejnego Sprintu. Chodzi o zapewnienie, że kiedy zacznie się Planowanie Sprintu, elementy na szczycie listy w Backlogu Produktu będą na tyle małe i na tyle zrozumiałe, by Zespół potrafił stworzyć prognozę osiągnięcia sensownego Celu Sprintu poprzez ich realizację.

Warto podkreślić, że oszacowania nigdy nie powinny być celem, dla którego szacowanie się odbywa. Innymi słowy, Zespół nie powinien dążyć do tego, by przede wszystkim przypisać jakieś oszacowanie do elementu Backlogu Produktu, ale do dobrego zrozumienia tego elementu. Jeśli jest ono na tyle nikłe, że ustalenie estymaty jest niemożliwe, to jej brak przypomina, że konieczna jest dalsza dyskusja lub poszukanie dodatkowych informacji.

Można wręcz powiedzieć, że szacowanie umożliwia podejmowanie różnych decyzji, ale też jako proces pomaga w uzyskaniu wspólnego zrozumienia zawartości Backlogu Produktu.

Oszacowania w trakcie Planowania Sprintu

Większość Zespołów Scrum uwzględnia potrzebę szacowania w trakcie pielęgnacji Backlogu Produktu i dokonuje go na różne sposoby. Są jednak takie Zespoły, które szacują dopiero w czasie Planowania Sprintu. Czy to błąd?

Najprawdopodobniej tak, choć kontekst jest tutaj kluczowy. Jest teoretycznie możliwe, że wszystkie elementy Backlogu Produktu, z jakimi Zespół ma do czynienia, są zawsze na tyle małe i zrozumiałe, że szacowanie nie będzie mu przynosić żadnych korzyści ani nie jest potrzebne.

W każdym innym przypadku rozpoczynanie Sprintu bez wcześniejszej choćby zgrubnej oceny, jak dużo pracy wymaga realizacja poszczególnych elementów Backlogu Produktu, to pomysł karkołomny. Nie dość, że istnieje wtedy ryzyko realizowania rzeczy nieopłacalnych (zbyt kosztownych), to jeszcze samo Planowanie Sprintu będzie wyjątkowo trudne. Zespół może nie dysponować wiedzą niezbędną do sporządzenia realistycznej prognozy, przez co potencjalnie cały Sprint nie przyniesie żadnej wartości.

Kiedy kończy się ważność oszacowań?

Planowanie Sprintu polega na tym, że Zespół decyduje o trzech rzeczach:

  1. Jaki Cel Sprintu zamierza osiągnąć w ramach rozpoczynającej się iteracji, czyli po co w ogóle odbywa się ten Sprint?
  2. Które elementy Backlogu Produktu zostaną zrealizowane, w szczególności po to, by osiągnąć Cel Sprintu?
  3. W jaki sposób prognozowane zmiany w produkcie zostaną wykonane przed końcem iteracji, by powstał produkt spełniający obowiązującą w Zespole Definicję Ukończenia?

Czy oszacowania elementów Backlogu Produktu, jakie zostały ustalone jakiś czas wcześniej, będą przydatne w ramach Planowania Sprintu? I czy powinny stanowić podstawę do podjęcia konkretnych elementów do realizacji?

Oczywiście, że nie – mogą być jedynie podpowiedzią, a i to należy traktować je ostrożnie. Z faktu, że estymata elementu jest taka czy inna nie wynika przecież, czy w tym konkretnym Sprincie Developerzy będą w stanie faktycznie go zrealizować. Może tak, może nie.

W rzeczywistości, o ile Zespół świadomie planuje swoje Sprinty, dokonuje ponownego oszacowania każdego elementu Backlogu Produktu, którego podjęcie do realizacji rozważa. Inaczej mówiąc, oryginalne oszacowania, jeśli zostały ustalone w ramach pielęgnacji Backlogu Produktu, tracą swoją ważność – bo nie powstały po to, by ułatwiać Planowanie, ale by pozwolić się do niego przygotować.

W ramach Planowania Sprintu Zespół musi zrobić dokładnie to, czego nie powinien robić wcześniej (na etapie pielęgnacji Backlogu Produktu): oszacować czasochłonność realizacji konkretnego planu implementacji elementów Backlogu Produktu. Bo teraz wiadomo już:

  • kto bierze udział w Sprincie,
  • jaki jest bieżący stan produktu,
  • jakimi możliwościami dysponuje Zespół.

Skoro Planowanie Sprintu wymaga stworzenia planu realizacji, a więc wybrania konkretnego rozwiązania, które ma zostać wytworzone przed zakończeniem iteracji, zabawa w porównywanie wielkości, story pointy i inne planning pokery nijak w tym nie pomoże.

Chybiony cel szacowania, czy ukryty problem?

Jeśli więc Zespół szacuje w ramach Planowania Sprintu elementy Backlogu Produktu z użyciem technik i form estymat takiej, jaka pasowałaby do pielęgnacji Backlogu Produktu, warto zapytać, po co to robi?

Możliwa jest niestety taka odpowiedź, że uzyskane oszacowania (np. w story pointach), zderzone następnie ze średnią wartością velocity Zespołu, będą wyznacznikiem tego, „ile można wciągnąć do Sprintu”. Zamiast tworzyć plan działania i dokonać oceny możliwości jego realizacji, Zespół zakłada wtedy, że do Sprintu bezpiecznie może podjąć elementy Backlogu Produktu wyszacowane w sumie na mniej więcej taką samą liczbę story pointów, jaką podpowiada średnie velocity.

W tej sytuacji Scrum Master powinien pilnie zabrać się za edukowanie Zespołu, na czym polega Planowanie Sprintu w Scrumie i czym jest empiryzm. A jeśli to z jego inicjatywy tak wygląda sytuacja, wtedy powinien najpierw się dokształcić lub przekazać Zespół w lepsze ręce, żeby mu dalej nie szkodzić.

Jeśli już Zespół chce bawić się w wyliczanie velocity i używać go w trakcie Planowania Sprintu, może to zrobić dużo sensowniej: ustalić Cel Sprintu, uzgodnić prognozę wraz z planem jej realizacji, a potem zobaczyć, jaką prędkość pozwoli to potencjalnie uzyskać. Jeśli byłaby ona skrajnie różna od typowego velocity, być może plan nie jest realistyczny – ale równie dobrze oszacowania niektórych z elementów Backlogu Produktu, podjętych do realizacji, są po prostu mocno nietrafione (wtedy można je zmienić).

W ten sposób prędkość Zespołu, zamiast być kluczem do Planowania Sprintu, stanie się jednym z mechanizmów bezpieczeństwa, który ma szansę ujawnić, że plan jest zbyt ambitny, albo nadmiernie zachowawczy.

Wszystkich zainteresowanych pogłębieniem tego tematu zapraszam na warsztaty szacowania i prognozowania w Agile. Jak zawsze z kodem 10MPRO zapisać można się na moje szkolenia z dziesięcioprocentową zniżką.