Ken Schwaber & Jeff Sutherland

Scrum Vodič
Ultimativni Vodič o Scrumu: Pravila Igre

November 2020

Namen Scrum Vodiča
Scrum sva razvila v zgodnjih devetdesetih letih. Prvo verzijo Scrum Vodiča sva napisala leta
2010 z namenom, da bi ljudje širom po svetu razumeli Scrum. Od takrat dalje Vodič nenehno
posodabljava in skupaj stojiva za njim.
Scrum Vodič vsebuje definicijo Scruma. Vsak element ogrodja ima točno določen namen, ki
bistveno prispeva k skupni vrednosti in rezultatom, ki jih želimo doseči s Scrumom.
Spreminjanje osnov in temeljnih idej Scruma, izpuščanje njegovih ključnih elementov ali
neupoštevanje pravil zgolj prikrije probleme in omeji pozitivne učinke Scruma, lahko celo
pripelje do njegove neuporabnosti.
Spremljava naraščajočo uporabo Scruma v današnjem vedno bolj kompleksnem svetu.
Počaščena sva, da se Scrum vpeljuje in uporablja tudi na področjih, ki presegajo domeno razvoja
programske opreme, v kateri ima Scrum korenine. S širjenjem uporabe Scruma lahko razvijalci,
raziskovalci, analitiki, znanstveniki in ostali strokovnjaki bolje opravijo svoje delo. Izraz“razvijalci” uporabljava zaradi poenostavitve in zajema vse, ki jim Scrum prinaša vrednost.
Pri uporabi Scruma je dovoljena vpeljava in uporaba raznih tehnik in pristopov, ki so v skladu zogrodjem Scruma, kot je opisan v tem dokumentu. Njihov opis in razlaga presegata namen tega
Scrum vodiča, saj je uporaba le-teh prilagojena posameznemu primeru uporabe Scruma.
Konkretni nasveti za njihovo uporabo v okviru Scruma se med seboj precej razlikujejo in so
opisani drugje.
Ken Schwaber & Jeff Sutherland November 2020

© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing thisScrum Guide, you acknowledge and agree that you have read and agree to be bound by the termsof the Attribution Share-Alike license of Creative Commons.

1

Namen Scrum Vodiča .................................................................................................................................... 1
Scrum Definicija ............................................................................................................................................ 3
Scrum Teorija ................................................................................................................................................ 3
Transparentnost ........................................................................................................................................ 3
Pregled ...................................................................................................................................................... 4
Prilagoditev ............................................................................................................................................... 4
Scrum Vrednote ............................................................................................................................................ 4
Scrum Team .................................................................................................................................................. 4
Developers ................................................................................................................................................ 5
Product Owner .......................................................................................................................................... 5
Scrum Master ............................................................................................................................................ 6
Scrum Dogodki .............................................................................................................................................. 7
Sprint ......................................................................................................................................................... 7
Sprint Planning .......................................................................................................................................... 8
Daily Scrum ............................................................................................................................................... 8
Sprint Review ............................................................................................................................................ 9
Sprint Retrospective.................................................................................................................................. 9
Scrum Artefakti ........................................................................................................................................... 10
Product Backlog ...................................................................................................................................... 10
Zaveza: Product Goal .......................................................................................................................... 10
Sprint Backlog ......................................................................................................................................... 11
Zaveza: Sprint Goal ............................................................................................................................. 11
Increment ................................................................................................................................................ 11
Zaveza: Definition of Done .................................................................................................................. 11
Zaključek ..................................................................................................................................................... 13
Zahvala .................................................................................................................................................... 13
Ljudje ................................................................................................................................................... 13
Zgodovina Scrum Vodiča ..................................................................................................................... 13
Prevod ..................................................................................................................................................... 13
Spremembe med Scrum vodičem 2017 in Scrum vodičem 2020 ............................................................... 142

Scrum Definicija
Scrum je enostavno ogrodje, ki pomaga posameznikom, ekipam in organizacijam ustvarjati
vrednost skozi prilagodljive rešitve za kompleksne probleme.
Na kratko, Scrum zahteva, da Scrum Master neguje okolje, v katerem:
1. Product Owner razvršča delo za kompleksne probleme v Product Backlog.
2. Scrum Team tekom Sprinta pretvarja izbrano delo v prirastek vrednosti, ki ga imenujemo
Increment.
3. Scrum Team in njihovi deležniki preverijo rezultate in se prilagodijo za naslednji Sprint.
4. Ponovimo
Scrum je enostaven. Preizkusite ga takega kot je in sami preverite, če vam njegova filozofija,
teorija in struktura pomagajo dosegati cilje in ustvarjati vrednost. Scrum ogrodje je namenoma
nepopolno in definira le dele, ki so potrebni za implementacijo Scrum teorije. Scrum je zgrajen
na skupnem znanju ljudi, ki ga uporabljajo. Namesto dajanja podrobnih navodil posameznikom,
pravila Scruma zgolj usmerjajo njihove odnose in interakcije.
Znotraj tega ogrodja se lahko uporabijo različni procesi, tehnike in metode. Scrum se lahko
kombinira in doda k obstoječim praksam, lahko pa jih naredi tudi nepotrebne. Scrum izpostavi
relativno učinkovitost trenutnega načina upravljanja, okolja in delovnih tehnik z namenom, da jihlahko izboljšamo.

Scrum Teorija
Scrum je zasnovan na empirizmu in vitkem (lean) razmišljanju. Empirizem poudarja, da znanje
izhaja iz izkušenj in da odločitve sprejemamo na podlagi opažanj. Vitko razmišljanje zmanjšuje
izgube in se osredotoča na bistvo.
Scrum uporablja iterativni, inkrementalni pristop s čimer optimizira napovedovanje in nadzoruje
tveganje. Scrum ekipe so takšne, da imajo ljudje skupaj vsa potrebna znanja in spretnosti, dalahko opravijo delo. Po potrebi znanja med seboj tudi delijo ali na novo pridobijo.
Scrum je sestavljen iz štirih predpisanih dogodkov za pregled in prilagoditev, vsi pa se zgodijo
znotraj dogodka, ki se imenuje Sprint. Ti dogodki so učinkoviti, ker implementirajo tri empirične
Scrum temelje: transparentnost, pregled in prilagoditev.

Transparentnost
Nastajajoča proces in delo morata biti vidna tako tistim, ki delo opravljajo, kot tudi tistim, za
kogar se delo opravlja. V Scrumu pomembne odločitve temeljijo na zaznanem stanju njegovih
treh predpisanih artefaktov. Artefakti z nizko transparentnostjo vodijo k odločitvam, ki znižujejo
vrednost in zvišujejo tveganje.
3

Transparentnost omogoča pregled. Pregled brez transparentnosti je zavajajoč in potraten.

PregledScrum artefakti in napredek v smeri dogovorjenega cilja morajo biti pregledani pogosto in
skrbno z namenom zaznave potencialnih nezaželenih odstopanj ali problemov. Ritem petih
Scrum dogodkov zagotavlja pomoč pregledom.
Pregled omogoča prilagoditev. Pregled brez prilagoditve je brez pomena. Scrum dogodki sooblikovani tako, da spodbujajo spremembe.

Prilagoditev
Če katerikoli vidik procesa odstopa preko sprejemljivih meja ali če končni produkt ni
sprejemljiv, je potrebno prilagoditi uporabljen proces ali izdelke, ki nastajajo. Prilagoditev je
potrebno izvesti čim prej, da se zmanjša nadaljnje odstopanje.
Prilagoditev postane težje izvedljiva, če vpleteni ljudje niso opolnomočeni ali nimajo možnosti
samoupravljanja (self-management). Od Scrum Teama se pričakuje, da se bo prilagodil v
trenutku, ko se bo pri pregledu naučil nekaj novega.

Scrum Vrednote
Uspešnost uporabe Scruma je odvisna od tega, kako ljudje sprejemajo in živijo pet vrednot :Zavzetost, Fokus, Odkritost, Spoštovanje in Pogum
Scrum Team je zavezan k doseganju svojih ciljev ter medsebojni pomoči in podpori. Njihov
glavni fokus je na nalogah in delu, ki so si ga zastavili v Sprintu, kar jim pomaga pri doseganju
zastavljenih ciljev. Scrum Team in njihovi deležniki se odkrito pogovarjajo o delu in izzivih.
Člani Scrum Teama spoštujejo drug drugega ter cenijo individualne kompetence in veščine.
Člani Scrum Teama imajo pogum za delanje pravih stvari in reševanje težkih problemov.
Te vrednote usmerjajo Scrum Team pri njihovem delu, dejanjih in obnašanju. Vsa dejanja,
sprejete odločitve in vsakodnevna uporaba Scruma, bi morali te vrednote okrepiti, ne pa
zmanjšati njihovega pomena. Člani Scrum Teama se učijo in raziskujejo vrednote ter spoznavajo
njihov pomen pri Scrum dogodkih in delu z artefakti. Utelešenje teh vrednot omogoči, da v polni
luči zaživijo empirizem in temelje Scruma: transparentnost, pregled in prilagoditev, kar dvigne
zaupanje med člani Scrum Teama.

Scrum Team
Osnovna enota v Scrumu je manjša skupina ljudi, imenovana Scrum Team. Scrum Teamsestavljajo en Scrum Master, en Product Owner in razvijalci, ki jih imenujemo Developers.
4

Znotraj Scrum Teama ni podskupin ali hierarhije. Gre za kohezivno enoto strokovnjakovosredotočenih na en cilj naenkrat in to je cilj produkta, ki ga imenujemo Product Goal.
Scrum Teami so multidisciplinarni, kar pomeni, da imajo člani vse potrebne veščine za
ustvarjanje vrednosti v vsakem Sprintu. Njihova lastnost je tudi samoupravljanje (selfmanagement), kar pomeni, da se interno sami odločajo, kaj bo kdo naredil, kdaj in kako.
Scrum Team je dovolj majhen, da ostaja gibčen in dovolj velik, da lahko dokonča omembe
vredno delo v okviru Sprinta, tipično je to 10 ali manj oseb. V splošnem smo ugotovili, damanjše skupine bolje komunicirajo in so bolj učinkovite. Če Scrum Teami postanejo preveliki,
naj razmislijo o reorganizaciji na več manjših kohezivnih Scrum Teamov, ki so vsi osredotočeni
na isti produkt. Potemtakem naj bi si delili isti Product Goal, Product Backlog in Product
Ownerja.
Scrum Team je odgovoren za vse aktivnosti vezane na produkt, od sodelovanja z deležniki,preverjanja, vzdrževanja, operative, eksperimentiranja, raziskav in razvoja do česarkoli drugega,
kar bi bilo potrebno. S strani organizacije je strukturiran in opolnomočen tako, da lahko sam
upravlja s svojim delom. Delo v Sprintih v ustaljenem ritmu izboljšuje osredotočenost in
doslednost Scrum Teama.
Celoten Scrum Team je odgovoren za ustvarjanje uporabnega in vrednega prirastka,
imenovanega Increment, v vsakem Sprintu. Scrum določa tri značilne odgovornosti znotraj
Scrum Teama: Product Owner, Scrum Master in Developers.

Developers
Osebe, ki so v Scrum Teamu zavezane k ustvarjanju kakršnegakoli vidika uporabnega
Incrementa v vsakem Sprintu imenujemo razvijalci oz. Developers.
Specifične veščine, ki jih potrebujejo Developers, so pogosto široke in se spreminjajo s
področjem dela. Kljub temu so Developers vedno odgovorni za:●●●●

Izdelavo načrta za Sprint, kar je Sprint Backlog;
Zagotavljanje kvalitete tako, da zadostijo Definition of Done;
Vsakodnevno prilagajanje načrta v smeri Sprint Goala; inZavezanost pri prevzemanju odgovornosti in doseganju visokih standardov

Product Owner
Product Owner je odgovoren za maksimiziranje vrednosti produkta, ki je rezultat dela Scrum
Teama. Kako se to doseže, se lahko zelo razlikuje in je odvisno od organizacije, Scrum Teamovin posameznikov.
Product Owner je odgovoren tudi za učinkovito upravljanje Product Backloga, kar vključuje:● Razvijanje in eksplicitno komuniciranje Product Goala;5● Kreiranje in jasno komuniciranje Product Backlog elementov;● Razvrščanje Product Backlog elementov; in● Zagotavljanje, da je Product Backlog transparenten, viden in razumljen.
Product Owner lahko zgornje opravi sam ali delegira drugim. Ne glede na to, je odgovornost
njegova.
Da lahko Product Owner uspe, mora celotna organizacija spoštovati njegove odločitve. Te
odločitve so vidne skozi vsebino in razvrščanje elementov na Product Backlogu ter skozi
preverljiv Increment na dogodku Sprint Review.
Product Owner je ena oseba, ne odbor. Product Owner lahko skozi Product Backlog predstavlja
potrebe večih deležnikov. Tisti, ki bi radi spremenili Product Backlog, lahko to naredijo tako, daprepričajo Product Ownerja.

Scrum MasterScrum Master je odgovoren za vzpostavitev Scruma, kot je definiran v Scrum Vodiču. To dosega
tako, da pomaga vsem razumeti Scrum teorijo in prakso, tako znotraj Scrum Teama, kot v celotniorganizaciji.
Scrum Master je odgovoren za učinkovitost Scrum Teama. To dosega tako, da omogoča Scrum
Teamu, da znotraj Scrum ogrodja izboljšuje svoje prakse.
Scrum Master je pravi vodja, ki služi Scrum Teamu in celotni organizaciji.
Scrum Master služi Scrum Teamu na več načinov, med drugim:● Usposablja člane skupine v samoupravljanju (self-management) in multidisciplinarnosti;● Pomaga Scrum Teamu osredotočati se na Incremente, ki dostavljajo visoko vrednost inzadostujejo Definition of Done;● Odstranjuje ovire, ki preprečujejo napredek Scrum Teama; in● Zagotavlja, da se Scrum dogodki zgodijo, so pozitivni, učinkoviti in znotraj časovnih
okvirjev.
Scrum master služi Product Ownerju na več načinov, med drugim:● Pomaga poiskati tehnike za učinkovito definicijo Product Goala in upravljanje ProductBackloga;● Pomaga Scrum Teamu razumeti potrebo po jasnih in jedrnatih Product Backlog
elementih;● Pomaga vzpostaviti empirično načrtovanje produkta v kompleksnem okolju; in● Po potrebi moderira sodelovanje z deležniki.
Scrum Master služi organizaciji na več načinov, med drugim:

6

● Vodi, usposablja in usmerja organizacijo pri vpeljavi in usvajanju Scruma;● Načrtuje in svetuje pri uvajanju Scruma znotraj organizacije;● Pomaga zaposlenim in deležnikom razumeti in sprejeti empirični pristop hkompleksnemu delu; in● Odstranjuje ovire med deležniki in Scrum Teami.

Scrum Dogodki
Sprint je ogrodje, znotraj katerega se zgodijo vsi ostali dogodki. Vsak Scrum dogodek jeformalna priložnost za pregled in prilagoditev Scrum artefaktov. Dogodki so namenoma
zasnovani tako, da omogočajo zahtevano transparentnost. Z izvajanjem dogodkov na način, ki jedrugačen od predpisanega, izgubimo priložnost za pregled in prilagoditev. Izvajanje Scrumu
dogodkov prinese rednost in zmanjša potrebo po sestankih, ki niso definirani v Scrumu. Zaradiželje po poenostavitvi je optimalno, da vsi dogodki potekajo ob istem času in na istem mestu.

SprintSprinti so srčni utrip Scruma, kjer se ideje spremenijo v vrednost.
Zaradi doslednosti imajo fiksno dolžino in trajajo en mesec ali manj. Nov Sprint se začne takoj
po zaključku prejšnjega Sprinta.
Vse delo, potrebno za dosego Product Goala, vključujoč dogodke Sprint Planning, Daily Scrum,
Sprint Review in Sprint Retrospective, je opravljeno znotraj Sprintov.
Med Sprintom:●●●●

Se ne dela sprememb, ki bi lahko ogrozile Sprint Goal;
Se ne zmanjšuje kvalitete;
Se po potrebi izboljša Product Backlog;
Se lahko na podlagi novih spoznanj in v dogovoru s Product Ownerjem prilagodi obseg
dela.

Sprinti z zagotavljanjem mesečnega ali še bolj pogostega pregleda in prilagoditve napredka v
smeri doseganja Product Goala izboljšajo predvidljivost. V primeru predolgih Sprintov lahko
postane Sprint Goal neveljaven oz. ničen, dodatno pa se lahko poveča kompleksnost in s tem
tveganje. Krajši Sprinti se uporabijo v primerih, ko želimo ustvariti več ciklov učenja in omejiti
tveganje glede stroškov in vloženega dela na krajše časovno obdobje. Vsak Sprint lahko
smatramo za kratek projekt.
Za beleženje in napovedovanje napredka obstajajo različne prakse, kot sta recimo burn-down inburn-up diagrama ali diagram, ki prikazuje kumulativen tok (cumulative flow). Čeprav so se
izkazale za koristne, ne morejo nadomestiti pomena empirizma. V kompleksnih okoljih namreč
velja, da ni znano, kaj se bo zgodilo. Za napovedovanje in sprejemanje odločitev lahko
uporabimo zgolj tisto, kar se je že zgodilo.
7

Sprint lahko predčasno prekinemo zgolj v primeru, ko Sprint Goal postane ničen in le Product
Owner ima pristojnost, da to naredi.

Sprint Planning
Sprint se prične s Sprint Planningom, na katerem se določi delo, ki bo narejeno v Sprintu.
Rezultat je načrt, ki je narejen ob sodelovanju celotnega Scrum Teama.
Product Owner zagotovi, da so udeleženci pripravljeni na diskusijo glede najbolj pomembnih
Product Backlog elementov in kako so le-ti povezani s Product Goalom. Scrum Team lahko na
Sprint Planning povabi tudi druge osebe, ki jim lahko pomagajo z nasveti.
Sprint Planning naslavlja naslednje teme:
Prva tema: V čem je vrednost tega Sprinta?
Product Owner predlaga, kako se lahko v trenutnem Sprintu produktu poveča vrednost in
uporabnost. Celoten Scrum Team potem sodeluje pri definiranju Sprint Goala, ki sporoča, kaj jevrednost Sprinta za deležnike. Sprint Goal mora biti finaliziran pred koncem Sprint Planninga.
Druga tema: Kaj je lahko narejeno v tem Sprintu?
Developers v diskusiji s Product Ownerjem izberejo tiste Product Backlog elemente, ki jih bodo
vključili v trenutni Sprint. Scrum Team lahko skozi proces te elemente tudi izpopolni, kar
izboljša njihovo razumevanje in dvigne samozavest ekipe.
Določiti, koliko bo narejeno v Sprintu, je lahko zahtevno. Vendar, bolj kot Developers poznajo
svoje pretekle rezultate, prihajajočo kapaciteto in Definition of Done, bolj samozavestni so lahkov napovedovanju Sprintov.
Tretja tema: Kako bo izbrano delo narejeno?
Za vsak izbran Product Backlog element, Developers načrtujejo potrebno delo za izdelavo
Incrementa, ki je v skladu z Definition of Done. To se pogosto naredi tako, da se ProductBacklog elemente razgradi v manjše delovne naloge, ki jih je možno narediti v največ enem
dnevu. Kako se to naredi, je popolnoma v domeni Developers. Nihče jim ne narekuje, kako naj
Product Backlog elemente spreminjajo v Incremente vrednosti.
Sprint Goal, Product Backlog elementi izbrani za Sprint in načrt za izvedbo, se skupaj imenujejo
Sprint Backlog.
Sprint Planning je časovno omejen na osem ur za enomesečni Sprint. Pri krajših Sprintih je ta
dogodek ponavadi krajši.

Daily Scrum
Namen Daily Scruma je preveriti napredek v smeri Sprint Goala in po potrebi prilagoditi Sprint
Backlog ter prihajajoče načrtovano delo.
8

Daily Scrum je 15-minutni dogodek, namenjen Developers določenega Scrum Teama. Zaradi
poenostavitve poteka vsak delovni dan Sprinta, vedno ob istem času in na istem mestu. ČeProduct Owner ali Scrum Master tudi aktivno delata na delovnih nalogah Sprint Backloga, sedogodka udeležita kot Developers.
Developers lahko uporabljajo poljubno strukturo in tehnike, dokler je njihov Daily Scrum
osredotočen na napredek v smeri Sprint Goala in rezultira v obliki akcijskega načrta za naslednji
delovni dan. To ustvarja fokus in izboljšuje samoupravljanja (self-management).
Daily Scrum izboljšuje komunikacijo, identificira ovire, podpira hitro odločanje in posledično
odpravlja potrebo po ostalih sestankih.
Daily Scrum ni edini čas, ko Developers lahko prilagajajo svoj načrt. Pogosto se srečajo tudi
tekom dneva za bolj podrobne diskusije glede prilagajanja ali ponovnega planiranja preostankadela v Sprintu.

Sprint Review
Namen Sprint Review-a je pregledati rezultat Sprinta in določiti prihodnje prilagoditve. Scrum
Team predstavi rezultate svojega dela glavnim deležnikom in skupaj se pogovorijo o napredku v
smeri Product Goala.
Med dogodkom Scrum Team in deležniki pregledajo, kaj je bilo doseženega med Sprintom in kaj
se je spremenilo v njihovem okolju. Na podlagi teh informacij, vsi udeleženci skupaj razpravljajoo tem, kako naprej. Za boljše upoštevanje in izkoristek novih priložnosti se lahko tudi prilagodi
Product Backlog. Sprint Review je delovno srečanje in Scrum Team naj ga ne omeji le na
prezentacijo.
Sprint Review je predzadnji dogodek Sprinta, časovno omejen na največ štiri ure za enomesečni
Sprint. Pri krajših Sprintih je tudi ta dogodek ponavadi krajši.

Sprint Retrospective
Namen retrospektiv imenovanih Sprint Retrospective je načrtovati in določiti načine za
izboljšavo kvalitete in učinkovitosti.
Scrum Team pregleda, kako je potekal zadnji Sprint z vidika posameznikov, sodelovanja,
procesov, orodij, in Definition of Done. Elementi uporabljeni za pregled se pogosto razlikujejo
glede na področje dela. Identificira se zavajujoče predpostavke in raziskuje njihove izvore.
Scrum Team se pogovori, kaj je šlo med Sprintom dobro ter kakšni problemi so se pojavili inkako so se (ali niso) ti problemi odpravili.
Scrum Team poišče najbolj koristne spremembe za izboljšanje svoje učinkovitosti. Izboljšav znajvečjim učinkom se lotijo čim prej. Lahko se jih celo doda na Sprint Backlog za naslednji
Sprint.
9

Sprint Retrospective zaključuje Sprint. Časovno je omejen na tri ure za enomesečni Sprint. Pri
krajših Sprintih je tudi ta dogodek ponavadi krajši.

Scrum Artefakti
Scrum artefakti predstavljajo delo ali vrednost. Oblikovani so tako, da maksimizirajo
transparentnost ključnih informacij. Tako ima vsak, ki jih pregleduje, enako osnovo za
prilagoditve.
Vsak artefakt vsebuje zavezo zagotavljati informacije, ki izboljšujejo transparentnost inosredotočenost, na podlagi katerih se lahko meri napredek:● Za Product Backlog je to Product Goal.
● Za Sprint Backlog je to Sprint Goal.
● Za Increment je to Definition of Done.
Te zaveze obstajajo za krepitev empiričnosti in Scrum vrednot za Scrum Team in njihovedeležnike.

Product Backlog
Product Backlog je nastajajoč in urejen seznam vsega potrebnega za izboljšavo produkta. Je
edini vir dela, ki ga opravlja Scrum Team.
Product Backlog elementi, ki jih lahko Scrum Team naredi v enem Sprintu, se smatrajo za
pripravljene za izbor na Sprint Planning dogodku. Ponavadi dobijo ta nivo transparentnosti poaktivnostih izpopolnjevanja. Product Backlog izpopolnjevanje (refinement) je razčlenjevanje inpodrobnejše definiranje Product Backlog elementov v manjše in bolj natančno opisane elemente.
Ta aktivnost dodajanja podrobnosti, kot so opis, vrstni red in velikost poteka neprestano.
Lastnosti elementov se razlikujejo glede na tip dela.
Developers, ki bodo delo opravljali, so odgovorni za določanje velikosti oz. težavnosti
elementov. Product Owner lahko vpliva na Developers tako, da jim pomaga pri razumevanju in
iskanju kompromisov.

Zaveza: Product Goal
Cilj produkta imenovan Product Goal opisuje prihodnje stanje produkta, ki lahko služi kot cilj, ki
ga zasleduje Scrum Team. Product Goal je v Product Backlogu. Preostalo v Product Backlogu
nastane, da definira “kaj” bo izpolnilo Product Goal.
Produkt je sredstvo za dostavo vrednosti. Ima jasne omejitve, znane deležnike in dobro
definirane uporabnike ali stranke. Produkt je lahko storitev, fizični izdelek ali nekaj bolj
abstraktnega.

10

Product Goal je dolgoročen cilj za Scrum Team. Najprej morajo doseči (ali opustiti) en cilj,
preden se lotijo naslednjega.

Sprint Backlog
Sprint Backlog sestavljajo Sprint Goal (zakaj) in množica Product Backlog elementov izbranihza Sprint (kaj), kot tudi akcijski načrt za izdelavo in dostavo Incrementa (kako).
Sprint Backlog je načrt, ki ga Developers naredijo zase. Gre za zelo pregledno sliko, ki v
realnem času odraža delo, ki ga Developers načrtujejo narediti med Sprintom, da dosežejo Sprint
Goal. Posledično se Sprint Backlog skozi Sprint posodablja na podlagi novih informacij inugotovitev. Vseboval naj bi dovolj podrobnosti, da lahko na Daily Scrumu preverjajo napredek.

Zaveza: Sprint Goal
Sprint Goal je edini cilj Sprinta. Čeprav je Sprint Goal zaveza od Developers, zagotavlja
fleksibilnost v smislu konkretnega dela, potrebnega za dosego le tega. Sprint Goal ustvarja tudi
povezanost in fokus, ter spodbuja Scrum Team, da deluje enotno, namesto na ločenih iniciativah.
Sprint Goal je ustvarjen med Sprint Planning dogodkom in nato dodan v Sprint Backlog. Ko
Developers delajo med Sprintom, imajo v mislih Sprint Goal. Če se delo izkaže za drugačno, kot
so predvidevali, se posvetujejo s Product Ownerjem glede spremembe obsega Sprint Backloga
znotraj Sprinta brez vpliva na Product Goal.

Increment
Prirastek imenovan Increment je konkreten korak v smeri Product Goala. Vsak Increment je
dodatek k vsem prejšnjim Incrementom in je temeljito preverjen z zagotovilom, da vsi
Incrementi delujejo skupaj. Da bi dostavil vrednost, mora biti Increment uporaben.
Znotraj Sprinta je lahko ustvarjenih več Incrementov. Skupek vseh Incrementov je predstavljen
na Sprint Review-ju, kar podpira empiričnost. Increment se lahko deležnikom predstavi tudi predkoncem Sprinta. Sprint Review naj se nikoli ne jemlje kot mejnik za dostavo vrednosti, vrednost
se lahko dostavi tudi med Sprintom.
Delo, ki ne zadostuje Definition of Done, se ne more upoštevati kot del Incrementa.

Zaveza: Definition of Done
Definition of Done je formalni opis stanja Incrementa, ko ta doseže kriterije kvalitete, ki jezahtevana za produkt.
V trenutku, ko Product Backlog element doseže Definition of Done, se rodi Increment.
Definition of Done ustvarja transparentnost z zagotavljanjem skupnega razumevanja vseh, kaj jebilo opravljeno kot del Incrementa. Če Product Backlog element ne zadostuje Definition of11

Done, ne more biti končan ali predstavljen na Sprint Review-u. Namesto tega, se vrne na ProductBacklog za upoštevanje v prihodnje.
Če je Definition of Done za Increment del standardov neke organizacije, morajo to kot minimum
upoštevati vsi Scrum Teami. Če ni organizacijski standard, mora Scrum Team določiti Definitionof Done primeren za produkt.
Developers so dolžni upoštevati Definition of Done. Če na produktu dela več Scrum Teamov,
morajo v sodelovanju definirati skupen Definition of Done in se ga nato držati.

12

Zaključek
Scrum je brezplačen in na voljo v tem vodiču. Scrum, kot je tukaj opisan, je nespremenljiv.
Kljub temu, da je možno implementirati samo določene dele Scruma, rezultat tega ni Scrum.
Scrum obstaja zgolj v celoti in deluje dobro kot okvir za druge tehnike, metodologije in prakse.

Zahvala
LjudjeMed tisočimi ljudmi, ki so prispevali k Scrumu, bi morali izpostaviti tiste, ki so bili pomembni
na začetku: Jeff Sutherland je delal z Jeffom McKenno in Johnom Scumniotalesom, Ken
Schwaber je delal z Mikom Smithom in Chrisom Martinom, vsi skupaj pa so pri tem sodelovali.
V kasnejših letih so sodelovali številni drugi in brez njihove pomoči Scrum danes ne bi bil tako
izpopolnjen, kot je.

Zgodovina Scrum Vodiča
Ken Schwaber in Jeff Sutherland sta skupaj prvič predstavila Scrum leta 1995 na konferenci
OOPSLA. Prva javna in uradna definicija Scruma je bila v bistvu zgolj popis znanja, ki sta ga
Ken in Jeff pridobila v zadnjih nekaj letih.
Scrum Vodič dokumentira Scrum v obliki, kot sta ga Jeff Sutherland in Ken Schwaber razvijala,prilagajala in vzdrževala 30 let. Različni modeli, procesi in ugotovitve, ki dopolnjujejo Scrum
ogrodje in lahko prispevajo k višji produktivnosti, ustvarjeni vrednosti, kreativnosti inzadovoljstvom nad rezultati, so opisani v drugih virih.
Celotna zgodovina Scruma je opisana drugje. Prav posebna zahvala pa gre Individual Inc.,
Newspage, Fidelity Investments in IDX (now GE Medical), kjer je bil Scrum preizkušen in
dokazan.

PrevodTa priročnik je preveden iz izvirne angleške različice, ki so jo zagotovili zgoraj omenjeni avtorji.
Prevajalca: Voranc Kutnik in Matej Golob
Kontakt: voranc.kutnik@corpohub.com
LinkedIn: https://www.linkedin.com/in/voranckutnik/
Spletna stran: https://www.corpohub.com
Pri prevodu sva morala upoštevati zahtevo, da ni dovoljeno prevajati naslednjih Scrum izrazov:
Scrum, Product Goal, Definition of Done, Sprint, Sprint Planning, Daily Scrum, Sprint Review,
Sprint Retrospective, Sprint Goal, Scrum Team, Scrum Master, Product Owner, Developers,
Product Backlog, Sprint Backlog in Increment.

13

Spremembe med Scrum vodičem 2017 in Scrum vodičem 2020
Še manj predpisan
Z leti se je v Scrum vodič dodajalo vedno več predpisov. Scrum vodič 2020 skuša z odstranitvijo
in sprostitvijo nekaterih predpisov spet narediti Scrum minimalno zadostno ogrodje. Npr.
odstranjena so Daily Scrum vprašanja, bolj ohlapno so določeni atributi Product Backlog
elementov in elementi retrospektive v Sprint Backlogu, skrajšan je opis glede prekinitve Sprinta.
Ena ekipa, osredotočena na en produkt
Cilj je bil odpraviti koncept ekipe znotraj ekipe, ki je privedla do “posrednika” ali obnašanja “miin oni” med Product Ownerjem in razvijalsko ekipo, ki smo jo nekoč imenovali Development
Team. Zdaj obstaja le ena Scrum ekipa, osredotočena na isti cilj, s tremi različnimi sklopi
odgovornosti: PO, SM in Developers.
Uvedba pojma Product Goal
Scrum vodič 2020 uvaja pojem cilj produkta, ki ga imenujemo Product Goal in Scrum ekipi
prinaša fokus na večji in vreden cilj. Vsak Sprint mora produkt približati k splošnemu cilju
produkta.
Sprint Goal, Definition of Done in Product Goal
Prejšnje verzije Scrum vodiča so opisovale Sprint Goal in Definition of Done, niso pa jima daliidentitete. Nista bila čisto prava artefakta, ampak sta bila zgolj povezana z njimi. Verzija 2020 je
dodala pojem Product Goal in vnesla več jasnosti na tem področju. Vsak od treh artefaktov sedaj
vsebuje ‘zavezo’ do njih. Product Backlog ima Product Goal, Sprint Backlog ima Sprint Goal in
Increment ima Definition of Done, ki je sedaj brez narekovajev. Obstajajo zato, da zagotavljajo
preglednost in osredotočenost na napredek posameznega artefakta.
Samoupravljanje namesto samoorganiziranja
Prejšnje verzije Scrum vodiča so razvojne skupine (Development Teams) označevali kot
samoorganizirajoče se, kar pomeni, da so sami odločali, kdo in kako bodo opravili delo.
Verzija 2020 pa se bolj osredotoča na celo Scrum ekipo in poudarja samoupravljanje, kar
pomeni, da se Scrum ekipa poleg kdo, kako, sama odloča tudi, na čem bo delala.
Tri Sprint Planning teme
Poleg dveh že obstoječih Sprint Planning tem “Kaj” in “Kako” je Scrum vodič 2020 dodal inpoudaril še tretjo temo “Zakaj”, ki se nanaša na Sprint Goal.
Splošna poenostavitev jezika za širšo publiko
V Scrum vodiču 2020 je poudarek na odpravi odvečnih in zapletenih izjav ter odstranitvi
morebitnih preostalih navezav na področje IT (npr. testiranje, sistem, zasnova, zahteve itd.).
Scrum vodič ima sedaj manj kot 13 strani.
14