Postanowiłem stworzyć mroczną listę tego, co uznawane jest za część Scruma lub wymaganą w nim praktykę, a czego robić nie trzeba, nie warto, a co czasami potrafi nawet zaszkodzić.

Jest to zatem mieszanina mitów, nieporozumień i przekłamań, z którymi każdy użytkownik metody na pewno się zetknął, niekoniecznie zdając sobie z tego sprawę.

Dla wygody pogrupowałem opisywane rzeczy tematycznie, a każdą opatrzyłem nagłówkiem, który podpowiada, czego można spodziewać się poniżej. A że w trakcie pisania tekst zaczął mi się szybko rozrastać, podzieliłem go na kilka części, z których pierwsza dotyczyć będzie Backlogu Produktu.

Mit 1: historyjki użytkownika są obowiązkowe

Na pierwszy ogień idą historyjki użytkownika (ang. user stories), czyli praktyka, którą można posłużyć się w procesie ustalania potrzeb użytkowników produktu. Scrum oczywiście nie wymaga jej stosowania, a już w szczególności nie ma żadnego sensu, by wszystkie elementy Backlogu Produktu próbować traktować jako historyjki użytkownika.

Raz, że wiele elementów dotyczyć będzie potrzeb interesariuszy niebędących użytkownikami (np. inwestorów). A dwa, że takie redukowanie historyjek wyłącznie do formy zapisu elementów Backlogu nie ma ze wspomnianą praktyką nic wspólnego. Jej kluczową częścią jest dyskusja, a nie same zapisane artefakty (czyli historyjki).

Mit 2: elementy Backlogu Produktu mają mieć jednolitą formę

Drugie nieporozumienie to dążenie do posłużenia się zawsze i do wszystkiego jedną formą elementów Backlogu Produktu. Najczęściej skutkuje to powstaniem listy pseudohistoryjek użytkowników. Bywa, że wszystko „musi być” wymaganiem. Zdarza się też, że Backlog zapełniają z góry na dół zadania, czyli zlecenia wykonania konkretnych prac przez Developerów.

Dążenie do bezsensownego ujednolicenia formy prowadzi do karkołomnych zabiegów polegających np. na tworzeniu potworków w rodzaju „Jako tabela bazy danych chcę, aby…”. Albo powoduje, że Backlog przypomina plan prac developerskich w Sprincie lub wręcz klasyczny plan projektu.

Tymczasem Scrum wymaga jedynie, by zawrzeć w Backlogu Produktu takie elementy, których realizacja skutkuje wzrostem wartości produktu i przybliża go do wytyczonego przez Product Ownera Celu Produktu. Na jednej liście mogą więc znaleźć się historyjki użytkownika, zgłoszenia błędów, wymagania biznesowe, problemy techniczne do rozwiązania – cokolwiek, co ma sens, jest potrzebne, wartościowe i zrozumiałe.

Mit 3: definiowanie kryteriów akceptacji jest obowiązkowe

Praktyka sporządzania kryteriów akceptacji (ang. acceptance criteria) ma w Scrumie wyjątkowego pecha. Jeśli już nie są one błędnie utożsamiane z Definicją Ukończenia, to wiele Zespołów sporządza je pieczołowicie w przekonaniu, że są czymś obowiązkowym. W ich przekonaniu element Backlog Produktu jest wybrakowany i wymaga pielęgnacji, jeśli jeszcze nie ma zdefiniowanych kryteriów akceptacji.

Zdarza się, że to przekonanie przesiąka do Definicji Ukończenia nawet tam, gdzie wszyscy mają świadomość, że Definicja i kryteria to dwie różne rzeczy. Pojawia się wtedy w Definicji wymóg, by wszystkie kryteria akceptacji tego, nad czym Developerzy pracowali, były spełnione. Jest to z pozoru tylko sensowne, bo opiera się o złudne przekonanie, że kryteria te są na pewno trafne. A przecież może zdarzyć się, że zupełnie wartościowy, działający i nadający się do użycia produkt powstanie, mimo iż jakieś pojedyncze kryterium nie zostało spełnione…

Kryteria akceptacji mogą być przydatne, ale w Scrumie nie jest wymagana praktyka ich sporządzania. W istocie warto po nią sięgnąć tam, gdzie pomaga lepiej zrozumieć elementy Backlogu Produktu, przede wszystkim do określenia kluczowych warunków, bez których spełnienia ciężko mówić o wartościowym rozwiązaniu. W praktyce większość elementów nie będzie takich kryteriów posiadać, bo to, jakie rozwiązanie ostatecznie zostanie wytworzone, jest wynikiem decyzji podjętych dopiero w trakcie developmentu.

Mit 4: otwarte pytania i brak precyzji wykluczają rozpoczęcie realizacji

Wspomniane kryteria akceptacji bywają przez Zespoły Scrum nadużywane jako narzędzie do zapewniania „niezbędnej precyzji” elementów Backlogu Produktu. Bo przecież ta musi zaistnieć, aby dało się rozpocząć ich realizację.

Inaczej mówiąc, pokutuje przekonanie, że w trakcie Planowania Sprintu Developerzy mogą podjąć się realizacji tylko tego, co nie budzi żadnych wątpliwości. Wszelkie pytania bez odpowiedzi, jakikolwiek brak ustaleń szczegółów czy niespełnione zależności skutkować muszą uznaniem, że element jest niegotowy i wymaga dalszej pielęgnacji.

To oczywiście bzdura. O tym, co jest gotowe, a co wymaga dalszej pielęgnacji, decyduje Zespół. Jeśli uzna, że jakiś element jest wystarczająco zrozumiały, by już w trakcie developmentu poradzić sobie z niektórymi pytaniami i wątpliwościami, oraz jeśli jest przekonany, że da radę zaplanować realizację tego elementu tak, by ukończyć ją w trakcie jednego Sprintu – element ten jest gotowy. Tak po prostu.

Można więc planować realizację elementów, które roją się od pytań i niejasności, o ile tylko Developerzy twierdzą, że zdołają uzyskać stosowne odpowiedzi w trakcie Sprintu, a zabieganie o nie potraktują po prostu jako część developmentu.

Na marginesie dodam, że zastosowanie kryteriów akceptacji jako mechanizmu do zapewnienia precyzji opisu elementów Backlogu Produktu jest chybione również z tego powodu, że zasadniczo służyć one powinny do walidacji, a więc potwierdzenia wartości wytworzonego rozwiązania. Powinno więc być ich stosunkowo niewiele, a każde skupić należałoby na czymś kluczowym. Nadają się więc do uzupełniania elementów Backlogu szczegółami jak łopata do mycia okien.

Mit 5: Zespół musi stworzyć i stosować definicję gotowości

Pochodną niezdrowego dążenia do „obiektywnego” ustalenia, co można realizować, a co wymaga dalszej pielęgnacji, jest ustalenie przez Zespół definicji gotowości (ang. definition of ready). Definicja ta zawiera warunki, które element Backlogu Produktu ma spełnić, aby development dla niego można było rozpocząć. Praktyka jej sporządzania niekoniecznie jest w Scrumie korzystna, a już na pewno nie jest w nim wymagana ani nie stanowi jego części.

Zdarza się przy tym, że niektórzy mylą definicję gotowości z Definicją Ukończenia, przy okazji mieszając do tego jeszcze kryteria akceptacyjne. Po czym zaczynają bełkotać o ustalaniu w trakcie Planowania Sprintu jakiejś „definicji ukończenia” dla poszczególnych elementów Backlogu Produktu. Ze Scrumem nie ma to rzecz jasna nic wspólnego, ale to temat raczej na osobny artykuł, więc przejdźmy do kolejnego nieporozumienia.

Mit 6: elementy Backlogu Produktu muszą zostać wycenione

Żeby cokolwiek zaplanować, trzeba to wyszacować, prawda? No, niezupełnie prawda, ale takie jest przekonanie sporej rzeszy użytkowników Scruma. Co więcej, utrzymują oni, że szacowanie jest w nim wymagane, aczkolwiek mają kłopot ze wskazaniem, któreż to zapisy w Scrum Guide definiują ten obowiązek.

Nie dziwi mnie ta trudność, bo nie ma takiego zapisu. W istocie nie da się używać Scruma bez szacowania różnych rzeczy, bo szacowanie i prognozowanie jest integralną częścią procesu planowania. Niemniej ani forma, ani czas, ani nawet obowiązek szacowania elementów Backlogu w Scrumie nie istnieje. O wszystkim decyduje Zespół, dopierając praktyki, jakich potrzebuje i stosując proces, jaki uważa za skuteczny – definicja Scruma określa jedynie zręby tego procesu, a nie szczegóły.

Mit 7: story pointy to jedyna poprawna forma wycen

Tuż obok poprzedniego nieporozumienia można znaleźć kolejne, często z nim połączone – jest nim przekonanie, że w Scrumie, jeśli już się coś szacuje, to w story pointach, czyli bezwymiarowych jednostkach relatywnej wielkości, które przypisuje się poszczególnym elementom Backlogu Produktu. To przekonanie przekuło się na implementację niejednego narzędzia elektronicznego, w którym standardowymi, domyślnymi, a nierzadko jedynymi (tak, Jiro, o tobie mowa!) dopuszczalnymi wycenami są właśnie te w story pointach.

Relatywne szacowanie jest sensowną praktyką, ale istnieje wiele różnych technik szacowania i powiązanych z nimi form zapisu wycen. Istnieje nawet technika szacowania #NoEstimates, której cechą charakterystyczną jest to, że zamiast przypisywać wyceny do szacowanych elementów, kategoryzuje się je do jednej z trzech grup (dostatecznie jasne i małe, za duże i wymagające podziału, niejasne i wymagające dodatkowych informacji).

Scrum nigdy nie wymagał ani wciąż nie wymaga posługiwania się story pointami. Ba, w trakcie Planowania Sprintu, kiedy to Developerzy oceniają, co dadzą radę zrealizować do końca iteracji, ta forma wycen jest prawdopodobnie najmniej użyteczna, bo przede wszystkim trzeba oszacować czasochłonność planu prac nad poszczególnymi elementami Backlogu.

Mit 8: szacowanie wielkości jest właściwym sposobem wyceniania

W definicji Scruma w różnej formie od lat przewija się informacja o oszacowaniu wielkości elementów Backlogu Produktu, co nie tylko przekuwa się we wspomniane już nieporozumienie o obowiązkowych wycenach, ale też bywa interpretowane jako wskazanie, jaka ich forma jest w metodzie dopuszczalna.

Zdarza się więc, że Developerów poucza się, iż nie powinni dyskutować o czasochłonności, bo „w Scrumie szacuje się wielkość”. Efekty bywają upiorne: powstaje jakiś nieformalny przelicznik owej „wielkości” na czasochłonność. Zamiast wzrostu przejrzystości albo chociaż utrzymania jej poziomu, następuje zaciemnienie stanu spraw. Ludzie mówią jedno, a myślą co innego – niewykluczone, że dosłownie co innego, jeśli każdy w inny sposób przelicza wyceny ze „scrumowej wielkości” na sensowne dla niego.

Prawda jest taka, że szacowanie zawsze ma zapewnić informacje potrzebne do podjęcia jakiejś decyzji lub sporządzenia niezbędnej prognozy. Dlatego szacuje się różne rzeczy, w różnym czasie, z różnego powodu. Skoro tak, jest absurdem, żeby próbować za każdym razem szacować w ten sam sposób i sporządzać wyceny w jednej „jedynie słusznej” formie.

Mit 9: do sporządzania wycen należy użyć techniki Planning Poker

Ze wspomnianymi już nadinterpretacjami Scruma łączy się nierzadko przekonanie, że skoro story pointy są obowiązkowe, to konieczne jest posługiwanie się Planning Pokerem jako techniką szacowania. Co jest o tyle chybione, że wspomniane punkty powstały jako idea, zanim wymyślony został Planning Poker i mogą być stosowane niezależnie od niego również w połączeniu z innymi metodami (np. Wall Estimation).

Scrum rzecz jasna nie wymaga posługiwania się Planning Pokerem, a to, że jest on kojarzony bardzo mocno z tą metodą, niczego tu nie zmienia. Osobiście fanem tej techniki nigdy nie byłem, bo jest powolna i bardzo często źle stosowana – szacujący skupiają się na uzyskaniu wyceny, często przy tym nawet nie zadając sobie trudu, skąd właściwie wzięła się skala, którą się posługują, ani czym są same story pointy.

Znam sporo Zespołów, które z Planning Pokera zrezygnowały i odetchnęły z ulgą, aczkolwiek nie oznacza to, że jeśli ktoś z niego korzysta, robi coś źle. Tak, jak Scrum nie wymaga użycia tej techniki, tak również tego nie zakazuje.

Mit 10: kolejność elementów wynikać musi z priorytetów

Backlog Produktu uporządkowany powinien zostać wedle oczekiwanej przez Product Ownera kolejności ich realizacji – z tym pewnie nikt nie będzie polemizował. Schody zaczynają się, gdy pada pytanie, skąd ta kolejność się bierze. Standardowa odpowiedź brzmi: z priorytetów! Product Owner „priorytetyzuje” elementy na liście i w ten sposób informuje Developerów, co powinno być robione najpierw, a co później.

Wyobraźmy sobie, że produkt ma wielu interesariuszy, którzy nie mają wspólnej oceny tego, co jest priorytetowe. Może wręcz zdarzyć się, że dla każdego co innego będzie najważniejsze. Jeśli słyszą od Product Ownera, że „spriorytetyzował” Backlog, mogą mieć naiwną nadzieję, że ich kluczowa potrzeba znajdzie się na szczycie listy. Potem jednak widzą, że opisujący ją element umieszczony został dużo niżej, a może na samym końcu i w najlepszym przypadku są nieco skonfundowani, a bywa, że poczują się wprowadzeni w błąd.

Nie dojdzie do tego, jeśli Product Owner powie, że uporządkował Backlog, uwzględniając przy tym między innymi priorytety. Będzie jasne, że nie oznacza to, iż coś, co jest ważne dla interesariusza, zostało na pewno uznane za kluczowe również przez Product Ownera.

Niektórzy będą jednak dalej bronić tezy o „priorytetyzowaniu”, wskazując, że porządkowanie Backlogu to nic innego, jak sposób poinformowania przez Product Ownera, co on sam traktuje jako priorytetowe. Na upartego tak, ale z drugiej strony priorytet może mieć jedna rzecz nad pozostałymi, więc w komplecie z powyższą tezą konieczne jest przyjęcie, iż istnieje jakieś „stopniowanie priorytetów”. Stąd już tylko krok do logicznego fikołka, jakim jest stwierdzenie, że coś „ma najniższy priorytet”, czyli że nie ma niczego, co byłoby mniej ważne. A przecież priorytet to inaczej pierwszeństwo przed czymś…

Mit 11: Backlog Produktu to plan maksymalizacji ROI

ROI, czyli zwrot z inwestycji (ang. return on investment) to drugi, obok priorytetów, rzekomy klucz, jakim powinien posługiwać się Product Owner. Przecież odpowiada za zapewnienie wartości produktu, a ta będzie tym wyższa, im większe będzie ROI zrealizowanych w każdym Sprincie elementów Backlogu Produktu.

W myśl tej tezy, na początku listy znaleźć się powinno to, co najbardziej opłaca się zrobić, a tę opłacalność Product Owner powinien jakoś wyliczyć, np. zderzając szacowane zyski z szacowanym kosztem wytworzenia każdej zmiany w produkcie. Pięknie się to uzupełnia z domniemaną koniecznością szacowania wszystkich elementów Backlogu, nieprawdaż?

Oczywiście jest w tym ziarno prawdy, bo Product Owner faktycznie ma dążyć do uzyskania maksymalnej korzyści dla interesariuszy, jak to możliwe. Niemniej nie może to polegać na bezmyślnym przeliczaniu różnych oszacowań czy wskaźników ekonomicznych z przynajmniej trzech powodów.

Jednym jest istnienie obiektywnych zależności oraz np. wymogów prawnych. Inaczej mówiąc, Product Owner czasami musi coś zrobić, mimo że wcale nie chce i mimo że wygeneruje to właściwie wyłącznie koszty.

Drugim jest konieczność myślenia o pozyskiwaniu dla produktu nowych użytkowników, zagospodarowania nowych nisz na rynku itd. Jeśli Product Owner skupi się na robieniu tego, co najbardziej opłaca się aktualnie, gdy potrzeby użytkowników zaczną się zmieniać i zaczną produkt porzucać, może on okazać się nagle bezwartościowy.

Trzecia kwestia to konieczność zjednywania sobie sojuszników, a nierzadko prowadzenie wewnątrzkorporacyjnej polityki. Product Owner może zdecydować o zrobieniu czegoś zupełnie nieistotnego, co ucieszy tę jedną osobę, której przychylność pozwoli na uzyskanie rzeczy, bez której możliwości rozwoju produktu będą mocno ograniczone.

Dlatego w Scrumie Product Owner ustala po prostu kolejność realizacji elementów, tworząc z nich dynamicznie zmienny plan osiągnięcia Celu Produktu, do którego dąży wraz ze swoim Zespołem (albo Zespołami, jeśli jest ich wiele). I to z tego Celu wynika kolejność i zawartość Backlogu, a nie z takich czy innych priorytetów lub wyliczeń spodziewanego ROI.

Ciąg dalszy

W kolejnej części cyklu o kreatywnych pomysłach na alternatywy sposób korzystania ze Scruma opisuję typowe i mniej spotykane nieporozumienia związane z Planowaniem Sprintu.