Product Backlog, Sprint Backlog, Inkrement: Scrum osigurava maksimalnu transparentnost

Cjeloviti osvrt na Vodič za Scrum 2020.

Ovaj članak je dio serije članka o novom Vodiču za Scrum:

1. Autori Scruma objavili novi Vodič za Scrum! Što sve moram znati o njemu?
2. Vodič za Scrum 2020: Tko priča s korisnicima? Scrum tim! Tko radi? Scrum tim! Tko je odgovoran? Pa Scrum tim!
3. Product Backlog, Sprint Backlog, Inkrement: Scrum osigurava maksimalnu transparentnost
4. Sprint do cilja: Scrum tim mora jasno definirati i dugoročne i kratkoročne ciljeve

Artefakti u Scrumu

Scrum procesni okvir definira tri različita tipa artefakta: Product Backlog i Sprint Backlog sadrže informacije vezane za rad na produktu, a Inkrement predstavlja vrijednost toga rada. Osmišljeni su na način da maksimiziraju transparentnost ključnih informacija vezanih za rad, odnosno rezultate rada.  

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Na taj način svatko tko radi uvid, analizu, odnosno provjeru tih artefakata, ima istu osnovu za donošenje zaključaka i daljnju prilagodbu. Kada informacije koje proizlaze iz artefakata ne odgovaraju stvarnom stanju ili su nepotpune, tada proces odlučivanja koji se na njima temelji može rezultirati krivim odlukama, smanjenom mogućnosti isporuke maksimalne vrijednosti i povećanjem rizika. 

Novi Vodič za Scrum dodaje novi element cilja produkta i jasnije definira postojeće elemente cilja sprinta i definicije gotovog te ih usko povezuje s odgovarajućim artefaktima: 

• Cilj produkta (eng. Product Goal) je dugoročniji cilj koji Scrum tim želi postići razvojem produkta i on se obvezuje (eng. commitment) ispuniti taj cilj. Put do ostvarenja tog cilja je definiran kroz Product Backlog.
• Cilj sprinta (eng. Sprint Goal) kratkoročni je cilj koji Scrum tim želi postići u svakom pojedinom sprintu jer se ostvarenjem tog cilja približavaju ostvarenju cilja produkta. Scrum tim se obvezuje ispuniti cilj za svaki sprint. Put do ostvarenja tog cilja definiran je kroz Sprint Backlog toga sprinta.
• Definicija gotovog (eng. Definition of Done) definira kriterije kvalitete koje Scrum tim želi ugraditi u produkt i to radi kroz popis aktivnosti koje moraju biti napravljene da bi rad na nekoj stavci bio gotov. Scrum tim je u obvezi poštivati svoju definiciju gotovog i tu obvezu dokazuje kroz razvoj Inkremenata koji su u skladu s tom definicijom.

U ovom nastavku serijala ćemo detaljno opisati Scrum artefakte, dok ćemo se u sljedećem baviti obvezama Scrum tima prema ostvarenju navedenih ciljeva i održanju kvalitete.

Product Backlog kao uređeni popis stavki za produkt

Product Backlog sadrži sav poznati posao vezan za razvoj i unaprjeđenje produkta. To je poredana lista stavki (eng. Product Backlog Item, skraćeno PBI) koja se kontinuirano mijenja i nadopunjuje kako rad na produktu napreduje i kako se mijenja okolina u kojoj se produkt koristi. Product Owner je vlasnik Product Backloga i dužan je učinkovito upravljati njegovim stavkama. To se u prvom redu odnosi na upravljanje sadržajem stavki pa Product Owner s developerima kontinuirano razrađuje stavke (eng. refinement) kako bi osigurao da su one jasno oblikovane i razumljive. Razrada stavki je aktivnost tijekom koje se stavke razbijaju na manje, preciznije stavke te im se dodaju atributi poput detalja, veličine i redoslijeda. Cilj razrade je učiniti stavke spremnima (eng. ready) tj. dovoljno jasnima i malima da se na njima može raditi u vremenski ograničenim sprintovima. 

The Product Backlog is an emergent, ordered list of what is needed to improve the product. […] Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Učinkovito upravljanje Product Backlogom se nadalje odnosi na upravljanje redoslijedom stavki. Product Owner određuje kakav će taj redoslijed biti uzimajući u obzir najrazličitije faktore poput njihove poslovne vrijednosti, rizika, povrata investicije koji se ostvaruje njihovom implementacijom i njihove međuovisnosti. Gledano od vrha prema dnu Product Backoga, redoslijed stavki će odražavati stav Product Ownera prema vrijednosti koja će se ostvariti implementacijom tih stavki u produktu. Drugim riječima, stavke na vrhu Product Backloga korisnicima uvijek donose najveću vrijednost u danom trenutku.

U prethodnoj verziji Vodiča za Scrum bilo je navedeno i kako su stavke pri vrhu Product Backloga obično razrađenije i spremnije za preuzimanje u sprint nego one koje se nalaze niže na Product Backlogu. Iako nova verzija Vodiča izostavlja takvu praksu, mi i dalje smatramo da takav način uređivanja Product Backloga ima svoje prednosti.

Naime, kao što smo gore razjasnili, stavke pri vrhu Product Backloga donose najveću vrijednost i zato ih je Product Owner tamo pozicionirao. Kada su one takve da su istovremeno i dobro razrađene i spremne za preuzimanje u sprint, tada proces planiranja sprinta postaje izuzetno efikasan jer se Product Owner i developeri moraju dogovoriti oko broja stavki koje stanu u sprint i razraditi ih do kraja. Veći dio posla analize, razrade i rasprave oko stavki je već unaprijed odrađen.

Kada Product Owner ovako upravlja Product backlogom, tada osigurava da Scrum tim uvijek radi na najvrjednijim stavkama s njegovog vrha, čime operativno maksimizira vrijednost koja nastaje kao rezultat rada Scrum tima u svakom sprintu.

Product Backlog kao jedinstveni izvor posla za Scrum tim

[The Product Backlog] is the single source of work undertaken by the Scrum Team.  [The Product Owner ensures]  that the Product Backlog is transparent, visible and understood.

Product Backlog predstavlja jedini izvor posla vezan za rad na produktu kojeg Scrum tim odrađuje u sprintevima. Dužnost je Product Ownera osigurati da Product Backlog bude transparentan, razumljiv i dostupan svim zainteresiranim stranama. Na taj su način svi uključeni u razvoj produkta, uključujući klijente i krajnje korisnike, kontinuirano i pravovremeno informirani o trenutnom statusu, stavkama koje su implementirane u produktu kao i stavkama na kojima se planira sljedeće raditi.

Sve zainteresirane strane koje žele nešto ugraditi u produkt ili nešto promijeniti moraju poštovati vlasništvo Product Ownera nad produktom te se dogovoriti s njim kako bi njihove želje bile ugrađene u Inkrement kroz kanal Product Backloga.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs. 

Kako developeri u Scrumu jedini operativno rade na izradi Inkremenata gotove funkcionalnosti koja je opisana kroz stavke Product Backloga, tako su oni i jedini u stanju davati izjave o veličini tih stavki. Oni koji posjeduju potrebne kompetencije i znanje potrebno za odraditi posao najbolje mogu reći koliki je opseg tog posla. Pod veličinom stavki se misli na neku vrstu procjene stavki i Vodič za Scrum u potpunosti prepušta developerima odabir praksi za procjenjivanje.

Diskusija i aktivnosti određivanja veličine stavki Product Backloga su sastavni dio gore opisane aktivnosti njihove razrade u kojoj zajednički sudjeluju Product Owner i developeri. Product Owner je dužan pomoći developerima razumjeti stavke i usmjeravati ih kada je potrebno raditi kompromise.

Sprint Backlog kao plan rada developera za svaki sprint

Rad Scrum tima je organiziran kroz vremenski ograničene sprintove koji započinju planiranjem sprinta (eng. Sprint Planning). Tijekom tog planiranja Scrum tim zajednički definira plan rada za developere za taj sprint. Taj plan se naziva Sprint Backlog i sastoji od tri stvari:

1. Cilja sprinta koji odgovara na pitanje zašto je sprint vrijedan odnosno kakvom vrijednošću za korisnike će on rezultirati;
2. Skupa stavki s Product Backloga koje će developeri preuzeti (s njegovog vrha) kroz diskusiju s Product Ownerom, a koji odgovara onome što se želi implementirati u sprintu;
3. Operativnog plana rada na preuzetim stavkama koji opisuje kako developeri namjeravaju isporučiti Inkrement i ostvariti cilj sprinta.

Sprint Backlog stoga čini vidljivim sav posao (aktivnosti) na odabranim stavkama Product Backloga kojeg developeri planiraju napraviti kako bi ispunili cilj sprinta. Taj posao se mijenja u realnom vremenu kroz sprint, zato što odražava nova saznanja do kojih developeri dolaze kroz konkretan rad na implementaciji stavki. Developeri su dužni održavati takvu razinu detalja Sprint Backloga koja je nužna za svakodnevan uvid u  napredak prema ostvarenju cilja sprinta tijekom dnevnog sastanka (eng. Daily Scrum).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned.

Ako razmišljate o praktičnoj implementaciji Sprint Backoga, tada razmišljajte o hijerarhijskoj listi gdje se na prvom nivou hijerarhije nalaze stavke s Product Backloga, a na drugom nivou zadaci koji su nastali razradom stavki i opisuju konkretan posao koji je potrebno odraditi da bi se odgovarajuća stavka implementirala. Developeri svakodnevno mijenjaju Sprint Backlog tako da dodaju i mijenjaju te zadatke, čime se sadržaj Sprint Backloga svakodnevno ažurira.

Posao za sprint je došao s Product Backloga i planiran je na njegovom početku. Ne postoje drugi izvori posla ili kanali kojima Scrum tim dobiva dodatni posao za vrijeme trajanja sprinta. To uključuje najrazličitije razine menadžera, odjele prodaje i marketinga te krajnje korisnike koji se svi nalaze izvan granica Scrum tima, a žele ostvariti neku svoju hitnu potrebu temeljem svojih organizacijskih ovlasti.

Kada bilo tko inzistira na tome da Scrum tim za vrijeme trajanja sprinta preuzme dodatni neplanirani posao koji ne dolazi s Product Backloga, tada on pokazuje grubo nepoštivanje prema Product Owneru i krši sve Scrum vrijednosti.

Inkrement kao jedini pokazatelj napretka Scrum Tima

Scrum tim je najkasnije na kraju sprinta u obvezi izgradnje upotrebljivog inkrementa produkta koji donosi novu vrijednost svojim korisnicima. To je ključno za mjerenje napretka Scrum tima. Svaki inkrement je unija inkrementa svih prethodnih sprintova i nove funkcionalnosti koja je implementirana u trenutnom sprintu. Tijekom sprinta, developeri mogu razviti više Inkremenata što je posebno zanimljivo iz perspektive modernih DevOps praksi za kontinuiranu izgradnju i isporuku softverskih produkata.

Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint.

Inkrement nastaje implementacijom pojedinačnih stavki sa Sprint Backloga i svaka pojedinačna stavka mora zadovoljavati dogovorene standarde kvalitete opisane kroz definiciju gotovog (eng. Definition of Done). Drugim riječima, implementacija svake stavke mora biti u skladu s tom definicijom. Upravo kroz redovitu i iterativnu izgradnju inkrementa sprint za sprintom, cijeli Scrum tim se transparentno približava ostvarenju cilja produkta. Svaki Inkrement se daje na uvid korisnicima i svim zainteresiranim stranama s ciljem da se od njih dobije što više povratnih informacija koje se ugrađuju u Product Backlog i uzimaju u obzir prilikom sljedećeg planiranja sprinta.

An Increment is a concrete stepping stone toward the Product Goal.

Želite li znati radi li Scrum tim dobro svoj posao, dovoljno mu je postaviti jedno jedino ključno pitanje: “Isporučujete li gotovi Inkrement na kraju svakog Sprinta?“.

Ako je odgovor negativan, tada se taj Scrum tim u svojem radu sigurno susreće s raznim izazovima. Ti izazovi mogu biti najrazličitije prirode, od nedostatne razrade stavki na Product Backlogu, loše odrađenog planiranja za sprint, manjka kompetencija za rad na Inkrementu, loše koordinacije i komunikacije u Scrum timu, manjkavosti alata koji developeri trenutno koriste, itd. Sve ovakve izazove je potrebno aktivno rješavati kroz naredne sprintove kako bi Scrum tim mogao izgrađivati gotove Inkremente.

Tekst su zajednički napisali Ana Roje Ivančić i Ognjen Bajić.