Scrum vodi

Uputstvo za Scrum:
Pravila igre








Jul 2013


Razvijaju i odravaju Ken Schwaber i Jeff Sutherland
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 2

Sadraj
Svrha Scrum vodia ......................................................................................................................... 3
Scrum definicija ................................................................................. Error! Bookmark not defined.
Scrum princip ..................................................................................... Error! Bookmark not defined.
Scrum tim ........................................................................................................................................ 4
Product Owner (Vlasnik proizvoda) ............................................................................................. 5
Razvojni tim ................................................................................................................................. 5
Scrum Master .............................................................................................................................. 6
Scrum dogaaji ................................................................................................................................ 7
Cilj Sprinta.................................................................................................................................... 7
Sprint ........................................................................................................................................... 7
Sprint Planning ............................................................................................................................ 8
Daily Scrum (Dnevni Scrum) ...................................................................................................... 10
Sprint Review (Pregled Sprinta) ................................................................................................. 11
Sprint Retrospective (Osvrt na Sprint)....................................................................................... 11
Scrum artefakti .............................................................................................................................. 12
Product Backlog ......................................................................................................................... 12
Sprint Backlog ............................................................................................................................ 14
Inkrement .................................................................................................................................. 14
Transparenstnost artefakata ......................................................................................................... 14
Definition of Done (definicija zavrenoga) ................................................................................ 15
Zavrna napomena ........................................................................................................................ 16
Zahvalnice ...................................................................................................................................... 16
Ljudi ........................................................................................................................................... 16
Historija ..................................................................................................................................... 16
Prevod ....................................................................................................................................... 16
ta je novo u Scrum Vodiu 2013 u odnosu na verziju iz 2011 ..................................................... 17

1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 3
Svrha Scrum vodia
Scrum je okvir za razvoj i odravanje sloenih proizvoda. Ovaj vodi definie ta je Scrum.
Sastavni delovi Scrum definicije su odgovarajue uloge, dogaaji, artefakti kao i pravila koja ih
povezuju. Scrum su razvili Ken Schwaber i Jeff Sutherland; oni, kao autori, zajedno stoje iza
Scrum vodia.
Definicija Scruma
Scrum (imenica): okvir u kojem ljudi mogu raditi na sloenim dinaminim problemima, pri tome
efikasno i kreativno isporuujui proizvode najvie mogue vrednosti.
Scrum je:
jednostavan
lako razumljiv i
teko savladiv.
Scrum je procesni okvir za upravljanje razvojem sloenih proizvoda, u upotrebi od ranih 1990-ih.
Scrum nije proces ili tehnika za izradu proizvoda; on je pre svega okvir u kojem je mogue
primeniti razliite procese i tehnike. Sa ciljem poboljanja, Scrum omoguava jasno praenje
relativne efikasnosti aktivnosti upravljanja i razvoja proizvoda.
Scrum okvir ine Scrum timovi i odgovarajue uloge, dogaaji, artefakti i pravila. Svaka
komponenta okvira ima odreenu svrhu i neophodna je za uspeh i upotrebu Scrum-a.
Scrum pravila povezuju dogaaje, uloge i artefakte, odreujui meusobne veze i odnose.
Scrum pravila su opisana kroz kompletan ovaj dokument.
Specifine strategije za korienje Scrum okvira se razlikuju i nisu ovde opisane.
Princip Scruma
Scrum se bazira na ideji empirijske kontrole procesa ili empirizma. Empirizam tvrdi da znanje
dolazi iz iskustva i donoenja odluka na osnovu onoga to je poznato. Scrum koristi iterativni,
inkrementalni pristup sa ciljem poveanja izvesnosti i upravljanja rizicima.
Svaka primena empirijske kontrole procesa ima tri nosioca: transparentnost, nadgledanje i
prilagoavanje.

1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 4
Transparentnost
Svi bitni aspekti procesa moraju biti vidljivi uesnicima koji su odgovorni za krajnji rezultat.
Transparentnost zahteva da se ti aspekti definiu zajednikim standardom kako bi i posmatrai
procesa razumeli ono to gledaju.
Na primer:
Svi uesnici u procesu moraju da koriste standardizovane nazive koji se odnose na proces; i
Uesnici koji obavljaju posao kao i oni koji prihvataju proizvod rada moraju imati zajedniku
definiciju obavljenog (engl. Definition of Done)
Nadgledanje
Korisnici Scrum-a moraju redovno nadgledati Scrum artefakte i napredak kako bi uoili varijacije.
Nadgledanje ne treba da bude toliko uestalo da ometa svakodnevni rad. Nadgledanje je
najkorisnije kada ga paljivo provode kvalifikovani kontrolori i u kritinim takama procesa.
Prilagoavanje
Ukoliko se nadgledanjem utvrdi kako jedan ili vie aspekata procesa odstupaju izvan prihvatljivih
granica i da rezultujui proizvod nee biti prihvatljiv, proces ili materija koja se procesira se
moraju prilagoditi. Prilagoavanje se mora desiti to pre kako bi se umanjila dodatna
odstupanja.
Scrum, unutar Sprinta, propisuje etiri formalna dogaaja za nadgledanje i prilagoavanje, kao
to je opisano u delu Srum dogaaji ovog dokumenta:
Sprint Planning (Sastanak planiranja Sprinta)
Daily Scrum (Dnevni Scrum ili brifing)
Sprint Review (Pregled Sprinta)
Sprint Retrospective (Osvrt na Sprint)
Scrum tim
Scrum tim ine: Product Owner (Vlasnik proizvoda), Razvojni ili Development tim i Scrum Master.
Scrum timovi su samoorganizovani i viefunkcionalni. Samoroganizovanim timom ne upravljaju
drugi (izvan tima), nego sam tim odluuje kako najbolje obaviti posao. Viefunkcionalni tim
poseduje sve kompetencije potrebne za obavljanje posla bez zavisnosti od drugih (izvan tima).
Ovakav model Scrum tima ima za svrhu veu fleskibilnost, kreativnost i efikasnost.
Scrum timovi isporuuju proizvode iterativno i inkrementalno, poveavajui na taj nain
mogunost povratnih informacija (engl. feedback). Inkrementalne isporuke zavrenog proizvoda
omoguavaju da je potencijalno upotrebljiva verzija proizvoda uvek na raspolaganju.
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 5
Product Owner (Vlasnik proizvoda)
Product Owner (Vlasnik proizvoda) je odgovoran za uveavanje vrednosti proizvoda i za rad
Razvojnog tima. Nain na koji se ovo postie razlikuje se meu organizacijama, Scrum timovima i
pojedincima.
Product Owner je jedina osoba zaduena za upravljanje Product Backlog-om (radni ostatak, lista
zahteva za proizvod koje tek treba implementovati; op.prev.), to podrazumeva:
Jasnu formulaciju Product Backlog stavki;
Odravanje redoslijeda Product Backlog stavki kako bi se najbolje ostvarili ciljevi i zadaci;
Optimizovanje vrednosti posla kojeg obavlja Razvojni tim;
Vidljiv, transparentan i svima jasan Product Backlog koji pokazuje Razvojnom timu na emu
sledee treba raditi; i
Obezbeivanje potrebnog nivoa detalja u Product Backlog stavkama kako bi ih Razvojni tim
razumeo
Product Owner moe obavljati navedene aktivnosti ili delegovati Razvojnom timu, u svakom
sluaju Product Owner ostaje odgovoran za njih.
Product Owner je jedna osoba, a ne odbor. Product Owner moe predstavljati elje odbora u
Product Backlog-u, ali promenu prioriteta Product Backlog stavki moe obaviti samo Product
Owner.
Da bi Product Owner bio uspean, cela organizacija mora da potuje njegove ili njene odluke.
Odraz tih odluka su Product Backlog stavke i njihov redosled. Nikome nije omogueno da trai
od Razvojnog tima da radi na drugim zahtevima za proizvod, niti Razvojni tim sme da radi onako
kako drugi predlau.
Razvojni tim
Razvojni tim ine eksperti koji rade na stvaranju potencijalno isporuivih inkremenata proizvoda
na kraju svakog Sprinta, u skladu sa Definition of Done (definicijom obavljenog). Samo lanovi
Razvojnog tima rade na stvaranju inkrementa.
Struktura i ovlasti Razvojnog tima su takve da se lanovi sami organizuju i upravljaju svojim
radom. Takva saradnja optimizuje sveukupnu efikasnost i efektivnost Razvojnog tima.
Karakteristike Razvojnih timova su:
Razvojni timovi su samoorganizovani. Niko (ak ni Scrum Master) ne moe odreivati kako iz
Product Backlog stavki stvoriti potencijalno isporuive inkremente;
Razvojni timovi su viefunkcionalni i poseduju sve kompetencije neophodne za stvaranje
inkrementa proizvoda;
lan Razvojnog tima je Developer - Scrum ne priznaje druge titule u timu; nema izuzetaka za
ovo pravilo;
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 6
Scrum ne priznaje pod-timove Razvojnog tima, bez obzira na specifinosti zadataka koji
trebaju da budu obavljeni kao to su testiranje ili poslovna analiza; nema izuzetaka za ovo
pravilo;
Iako pojedini lanovi Razvojnog tima mogu imati specifine kompetencije i podruja na koja
se fokusiraju, odgovornost ostaje na Razvojnom timu kao celini.
Veliina Razvojnog tima
Optimalna veliina Razvojnog tima je dovoljno mala da tim bude ustar i istovremeno dovoljno
velika da tim moe da obavi znaajnu koliinu posla unutar Sprinta. Ukoliko Razvojni tim ima
manje od tri lana, smanjuje se interakcija i produktivnost. Manji Razvojni timovi mogu da imaju
potekoe u smislu potrebnih kompetencija tokom Sprinta, to uzrokuje nemogunost tima da
stvara potencijalno isporuiv inkrement. Tim sa vie od devet lanova zahteva i mnogo vie
koordinacije. Veliki Razvojni timovi poveavaju kompleksnost upravljanja empirijskim procesom.
Product Owner i Scrum Master u pravilu nisu deo Razvojnog tima, osim u sluajevima gde
uestvuju u aktivnostima na implementovanju Product Backlog stavki.
Scrum Master
Da Scrum bude razumljiv i primjenjiv odgovoran je Scrum Master (facilitator; op.prev.). Scrum
Master to postie pomaui Scrum timu da deluje u skladu sa Scrum idejama, praksom i
pravilima.
Scrum master je servant-leader (sluga-lider) Scrum tima. Scrum Master pomae onima izvan
Scrum tima da shvate koje vrste interakcija su korisne za tim a koje ne. Scrum Master pomae
svima da prilagode te interakcije kako bi pomogli uveanju vrednosti koju stvara Scrum tim.
Na koji nain Scrum Master radi za Product Owner-a
Scrum Master izvrava nekoliko aktivnosti pomaui Product Owner-u, kao to su:
Nalaenje tehnika za efikasno upravljanje Product Backlog stavkama;
Pomaganje Scrum timu da razume potrebu za jasnim i konciznim Product Backlog stavkama;
Razumevanje planiranja proizvoda u empirijskom okruenju;
Pomaganje Product Owner-u u da doe do redosleda Product Backlog stavki s ciljem
uveavanja (isporuene) vrednost;
Razumevanje i praktikovanje agilnosti; i
Omoguavanje i moderacija Scrum dogaaja po potrebi ili po zahtevu.
Na koji nain Scrum Master radi za Razvojni tim
Scrum Master izvrava nekoliko aktivnosti pomaui Razvojnom timu, kao to su:
Pomaganje Razvojnom timu da postane samoorganizovan i viefunkcionalan;
Pomaganje Razvojnom timu da stvori proizvode visoke vrednosti;
Uklanjanje prepreka koje ometaju napredak Razvojnog tima;
Omoguavanje i moderacija Scrum dogaaja po potrebi ili po zahtevu; i
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 7
Poduavanje Razvojnog tima u organizacijama gdje Scrum jo nije u potpunosti prihvaen i
razumljiv.
Na koji nain Scrum Master radi za organizaciju
Scrum Master izvrava nekoliko aktivnosti pomaui organizaciji, kao to su:
Uvoenje i voenje Scrum-a u organizaciji;
Planiranje implementacije Scrum-a u organizaciji;
Pomaganje zaposlenima i zainteresovanim stranama da rade u skladu sa Scrum okvirom i
empirijskim razvojem proizvoda;
Upravljanje promenama koje poveavaju produktivnost Scrum tima; i
Rad sa drugim Scrum Master-ima na poveanju efikasnosti primene Scrum-a u organizaciji.
Scrum dogaaji
Propisani Scrum dogaaji trebaju da se odravaju redovno i imaju za cilj umanjenje potrebe za
dodatnim sastancima koji nisu deo Scrum okvira. Svi dogaaji su vremenski ogranieni tako da
svaki od njih ima definisano maksimalno trajanje. Jednom kada Sprint zapone, njegova duina
je fiksirana i ne moe biti skraena niti produena. Preostali dogaaji se mogu zavriti im se
postigne cilj dogaaja, to znai da se investira odgovarajue vreme i da se ne dozvoljava
rasipanje.
Pored Sprinta, unutar kojeg se nalaze svi drugi dogaaji, svaki Scrum dogaaj je prilika za osvrt i
poboljanje (engl. inspect and adapt). Ovi dogaaji su osmiljeni s ciljem da omogue potrebnu
transparentnost i nadgledanje. Izostanak bilo kojeg od Scrum dogaaja ima za rezultat smanjenu
transparentnost i proputenu priliku za osvrt i poboljanje.
Cilj Sprinta
Cilj Sprinta odreuje ta e biti postignuto za vreme Sprinta implementovanjem Product Backlog
stavki - on je vodilja Razvojnom timu u procesu stvaranja inkrementa. Cilj se odreuje tokom
planiranja odnosno Sprint Planning sastanka.
Sprint
Centralni koncept Scrum-a je Sprint, vremenski ogranien na mesec dana ili krai vremenski
period, tokom kojeg se stvara upotrebljiv, potencijalno isporuiv inkrement proizvoda. Svaki
Sprint uobiajno ima konstantno trajanje tokom procesa razvoja. Novi Sprint poinje odmah po
zakljuivanju prethodnog.
Sprint se sastoji od sledeih dogaaja i aktivnosti: Sprint Planning (Sastanak planiranja Sprinta),
Daily Scrum (Dnevni Scrum ili brifing), razvoj proizvoda, Sprint Review (Pregled Sprinta) i Sprint
Retrospective (Osvrt na Sprint).

1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 8
U toku Sprinta:
Ne iniciraju se promene koje bi ugrozile Cilj Sprinta;
Ciljevi koji se odnose na kvalitet se ne mogu umanjiti;
Uz nove informacije i saznanja, obim posla se moe razjasniti i dodatno pregovarati izmeu
Product Owner-a i Razvojnog tima;
Svaki Sprint moe se smatrati projektom koji traje ne due od mesec dana. Kao i kod projekta,
Sprint se koristi da bi se neto postiglo. Svaki Sprint ukljuuje: definiciju onoga to treba
napraviti, dizajn i fleksibilan plan koji e voditi razvoj, aktivnosti na razvoju i dobijeni proizvod.
Maksimalno trajanje Sprinta je mjesec dana. Kod dueg Sprinta, plan onoga tp treba izraditi
moe da se promeni, kompleksnost moe da se povea, kao i rizik. Sprint omoguava
predvidljivost na nain da se nadgledanje napretka i poboljanje deava najmanje jednom
meseno. Sprint takoe ograniava troak rizika na kalendarski mesec.
Otkazivanje Sprinta
Sprint se moe otkazati i pre nego istekne. Samo Product Owner ima pravo da otkae Sprint,
iako on ili ona moe to uraditi pod uticajem interesnih strana, Razvojnog tima ili Scrum Master-
a.
Sprint bi mogao da se otkae u sluaju da Cilj Sprinta postane zastareo. To moe da se desi
ukoliko kompanija promeni pravac delovanja ili se promene uslovi trita i tehnologije.
Generalno, Sprint treba da se otkae ukoliko izgubi smisao u datim okolnostima. U svakom
sluaju, zbog kratkog trajanja Sprinta, otkazivanje retko ima smisla.
Pri otkazivanju Sprinta, ispituje se svaka zavrena Product Backlog stavka. Ako je deo
implementovanog potencijalno isporuiv, Product Owner e to najee prihvatiti. Sve
nedovrene Product Backlog stavke se ponovo analiziraju i vraaju u Product Backlog. Delimino
obavljeni posao na ovim stavkama vremenom gubi vrednost i takve stavke trebaju ponovno da
se procene.
Otkazivanje Sprinta iziskuje resurse s obzirom na to da svako treba da se pregrupie i organizuje
naredni Sprint Planning kako bi se zapoeo novi Sprint. Otkazivanje Sprinta esto je loe za tim i
vrlo se retko deava.
Sprint Planning
Posao koji treba da se obavi tokom Sprinta planira se na Sprint Planning sastanku. Ovaj plan se
stvara saradnjom celog Scrum tima.
Sprint Planning je vremenski ogranien na najvie osam sati za jednomeseni Sprint. Za krai
Sprint, ovaj dogaaj takoe traje krae. Scrum Master obezbjeuje da se dogaaj redovno
organizuje i da uesnici razumeju njegovu svrhu. Scrum Master poduava Scrum tim kako bi se
draoprevienog vremenskog okvira.
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 9
Sprint Planning odgovara na sledea pitanja:
ta se moe isporuiti s inkrementom koji e biti rezultat ovog Sprinta?
Kako e se ostvariti potrebne aktivnosti za stvaranje inkrementa?
Prva tema: ta se moe zavriti u ovom Sprintu?
Razvojni tim radi na proceni funkcionalnosti koja moe biti razvijena tokom Sprinta. Product
Owner razmatra ciljeve koje treba ostvariti tokom Sprinta i Product Backlog stavke kojima e se,
ukoliko se uspeno implementuju tokom Sprinta, ostvariti Cilj Sprinta. Ceo Scrum tim sarauje
na razumevanju posla koji treba da bude obavljen u Sprintu.
Ulazne informacije za ovaj sastanak su Product Backlog, poslednji inkrement proizvoda,
oekivani kapacitet Razvojnog tima tokom Sprinta i dosadanje performanse Razvojnog tima.
Broj odabranih Product Backlog stavki za Sprint zavisi od Razvojnog tima. Samo Razvojni tim
moe da proceni ta je mogue ostvariti u narednom Sprintu.
Nakon to Razvojni tim odredi Product Backlog stavke koje mogu da budu isporuene kao
rezultat narednog Sprinta, Scrum tim odreuje Cilj Sprinta. Cilj Sprinta je cilj koji e biti ispunjen
u okviru Sprinta realizacijom Product Backlog-a; on daje smernice Razvojnom timu u stvaranju
tog Inkrementa.
Druga tema: Kako e odreeni posao biti obavljen?
Nakon to Razvojni tim uspostavi Cilj Sprinta i listu Product Backlog stavki za Sprint, Razvojni tim
odluuje o tome kako implementovati odabranu funkcionalnost i stvoriti inkrement proizvoda
tokom Sprinta. Product Backlog stavke odabrane za ovaj Sprint zajedno s planom njihove
isporuke zove se Sprint Backlog.
Razvojni tim najee poinje tako to dizajnira nain i koliinu rada potrebnu za
implementovanje Product Backlog stavki u upotrebljiv inkrement proizvoda. Posao koji treba da
bude obavljen moe biti razliitog obima (engl. estimated effort). U svakom sluaju, Razvojni tim
planira onoliko posla za Sprint tokom Sprint Planning sastanka koliko smatra da moe biti
ostvareno. Do kraja Sprint Planning sastanka, posao planiran za prvih nekoliko dana Sprinta
esto se detaljnije analizira i ralanjuje na jednodnevne ili krae zadatke. Razvojni tim sam
organizuje nain implementovanja Sprint Backlog stavki tokom Sprint Planning sastanka, a po
potrebi i kasnije tokom Sprinta.
Product Owner pomae da razjasni odabrane Product Backlog stavke i odluuje izmeu
odreenih stavki ili njihovih delova. Ako Razvojni tim utvrdi da ima previe ili premalo posla, tim
i Product Owner mogu jo jednom da pregovaraju o listi Product Backlog stavki koje treba
implementovati. Razvojni tim moe takoe u diskusijama pozvati druge eksperte da doprinesu
svojim tehnikim ili domenskim znanjem i preporukama.
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 10
Do kraja Sprint Planning sastanka, Razvojni tim treba da bude u mogunosti da objasni Product
Owner-u i Scrum Master-u kako planira da ostvari dogovoreni plan i Cilj Sprinta i da stvori
oekivani inkrement proizvoda.
Daily Scrum (Dnevni Scrum)
Daily Scrum je 15-minutni dnevni brifing tokom kojeg Razvojni tim usklauje svoje aktivnosti i
stvara plan za narednih 24 sata. Ovo se ostvaruje osvrtom na posao koji je obavljen u periodu od
prethodnog Daily Scrum-a i predvianjem ta moe da se ostvari do sledeeg Daily Scrum-a.
Kako bi organizacija bila jednostavnija, Daily Scrum se odrava svakog dana u isto vreme na
istom mestu. Tokom sastanka, lanovi Razvojnog tima objanjavaju:
ta sam postigao/postigla jue to je doprinelo ostvarenju Cilja Sprinta?
ta u uraditi danas da doprinesem ostvarenju Cilja Sprinta?
Da li vidim bilo kakve prepreke koje utiu na mene ili Razvojni tim na nain da dovode u
pitanje ostvarenje Cilja Sprinta?
Razvojni tim koristi Daily Scrum za nadgledanje napretka prema Cilju Sprinta i za osvrt na to da li
je tim na pravom putu da obavi posao odreen Sprint Backlog stavkama. Daily Scrum optimizuje
verovatnou da Razvojni tim zaista ostvari Cilj Sprinta. Svakog dana, Razvojni tim treba da
razume na koji nain e, kroz samoorganizaciju, da ostvari Cilj Sprinta i stvoriti oekivani
inkrement na kraju Sprinta. Razvojni tim ili lanovi tima esto imaju potrebu za dodatnim
diskusijama nakon Daily Scrum sastanka, vezano za poboljavanja ili dodatna planiranja za
ostatak Sprinta.
Scrum Master obezbeuje da Razvojni tim obavlja ovaj sastanak, ali Razvojni tim je odgovoran za
sprovoenje Daily Scrum-a. Scrum Master poduava Razvojni tim kako da se dre predvienog
ogranienja od 15 minuta za Daily Scrum.
Scrum Master sprovodi pravilo prema kojem samo lanovi Razvojnog tima uestvuju na Daily
Scrum brifingu.
Daily Scrum poboljava komunikaciju, eliminie potrebu za drugim sastancima, otkriva prepreke
u radu koje treba otkloniti, podrava brzo donoenje odluka i nadograuje znanje Razvojnog
tima. To je kljuni sastanak za osvrt i poboljavanje.

1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 11
Sprint Review (Pregled Sprinta)
Sprint Review (Pregled Sprinta) se odrava krajem svakog Sprinta kako bi se pregledao
inkrement i po potrebi korigovao Product Backlog. Tokom Sprint Review sastanka, Scrum tim i
zainteresovane strane diskutuju o tome ta je uraeno tokom Sprinta. Na osnovu toga i
eventualnih promena Product Backlog stavki tokom Sprinta, uesnici diskutuju o narednim
koracima koji mogu optimizovati isporuenu vrednost. Ovo je neformalni sastanak a ne sastanak
za proveru statusa, a prezentacija inkrementa je namenjena da prikupi povrtane informacije i
podri saradnju.
Ovo je etverosatni sastanak za sluaj jednomesenog Sprinta. Kod kraeg Sprinta, ovaj dogaaj
je krai. Scrum Master obezbjeuje odravanje dogaaja kao i da uesnici razumeju njegovu
svrhu. Scrum Master poduava uesnike kako da se dre predvienog vremenskog okvira.
Sprint Review ukljuuje sledee elemente:
Uesnici su Scrum tim i kljune interesne strane koje poziva Product Owner;
Product Owner objanjava koje Product Backlog stavke su zavrene i ta nije zavreno;
Razvojni tim diskutuje o dobrim iskustvima tokom Sprinta, te o problemima na koje su naili
i kako su ih reili;
Razvojni tim prikazuje stavke koje su implementovane i zavrene i odgovara na pitanja u vezi
sa inkrementom;
U uesnike su ukljueni Scrum tim i glavne zainteresovane strane pozvane od strane Product
Owner-a;
Product Owner diskutuje trenutni Product Backlog. On ili ona na osnovu dosadanjeg
napretka mogu da procene datume kada mogu da se oekuju odreene funkcionalnosti;
Svi uesnici diskutuju o tome na emu se sledee treba raditi i ove informacije su ulaz za
sastanak Sprint Planning-a;
Pregledaju se promjene na tritu ili promene vezane za potencijalno korienje proizvoda i
u ovom kontekstu ta je najvrednije za sledeu implementaciju;
Pregledaju se vremenski okvir, budet, mogunosti i trite za narednu planiranu verziju
proizvoda.

Rezultat Sprint Review sastanka je pregledani Product Backlog koji definie mogue stavke za
naredni Sprint. Product Backlog takoe moe biti prilagoen u skladu s novim prilikama.
Sprint Retrospective (Osvrt na Sprint)
Sprint Retrospective (Osvrt na Sprint) je prilika za osvrt i stvaranje plana za poboljanja na
kojima e se raditi tokom narednog Sprinta.
Sprint Retrospective se odrava svakon svakog Sprint Review sastanka, a pre narednog
planiranja Sprinta. Ovo je trosatni sastanak kod jednomesenog Sprinta. Za sluaj kraeg Sprinta,
sastanak je krai. Scrum Master ogmouava odravanje sastanka kao i da svi uesnici razumeju
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 12
njegovu svrhu. Scrum Master poduava uesnike da se dre planiranog vremenskog okvira.
Scrum Master uestvuje kao lan tima u smislu odgovornosti za ceo Scrum proces.
Svrha Sprint Retrospective sastanka je:
Osvrtanje na poslednji Sprint u smislu ljudi, odnosa, procesa i alata;
Identifikovati znaajna pozitivna iskustva i potencijalna poboljanja;
Stvaranje plana za implementovanje poboljanja na nain koji odgovara Scrum timu.
Scrum Master podrava Scrum tim u poboljavanju, unutar Scrum okvira, razvojnog procesa i
prakse kako bi naredni Sprint bio jo efektivniji i prijatniji. Tokom svakog Sprint Retrospective
sastanka, Scrum tim planira kako da povea kvalitet proizvoda po potrebi poboljanjem
Definition of Done (definicije zavrenoga).
Do kraja Sprint Retrospective sastanka, Scrum tim treba identifikovati poboljanja koja e biti
implementirana tokom narednog Sprinta. Implementacija tih poboljanja tokom narednog
Sprinta je adaptacija samog Scrum tima. Iako poboljanja mogu da budu implementovana u bilo
kom momentu, Sprint Retrospective daje formalnu priliku da se tim fokusira na osvrt i
poboljanje.
Scrum artefakti
Scrum artefakti predstavljaju rad ili vrednosti koje obezbjeuju transparentnost i priliku za osvrt
i poboljanje. Artefakti koje definie Scrum su upravo odabrani kako bi poveali transparentnost
kljunih informacija tako da svako ima jednako razumevanje artefakta.
Product Backlog
Product Backlog je lista poredanih stavki koje mogu biti potrebne za proizvod i to je jedini izvor
zahteva za bilo koje promene koje se na proizvodu moraju implementovati. Product Owner je
odgovoran za Product Backlog, ukljuujui njegov sadraj, dostupnost i redosled stavki.
Product Backlog nije nikada zavren. Inicijalne verzije Product Backlog stavki odraz su inicijalno
poznatih i najjasnijih zahteva. Product Backlog se razvija zajedno sa proizvodom i okruenjem u
kojem se koristi. Product Backlog je dinamian; on se uvek menja kako bi identifikovao
odgovarajue kompetitivne i korisne promene na proizvodu. Dok postoji proizvod, postoji i
Product Backlog.
Product Backlog je lista svih zahteva, funkcionalnosti, poboljanja i popravki koji zajedno ine
promene koje treba da se implementuju u buduim inkrementima proizvoda. Product Backlog
stavke imaju opis, redosled, procenju i (poslovnu) vrednost.
Kako se proizvod koristi i kako raste njegova vrijednost, a trite prua povratne informacije,
Product Backlog postaje vea i detaljnija lista. Zahtevi nikada ne prestaju da se menjaju, tako da
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 13
je Product Backlog dinamini artefakt. Promjene u poslovnim zahtevima, uslovima na tritu ili u
tehnologiji mogu uzrokovati promene Product Backlog-a.
esto na istom proizvodu radi vie Scrum timova. Jedan Product Backlog se koristi za opis
narednih aktivnost na proizvodu. Dodatni opis Product Backlog stavki moe da se koristi za
njihovo grupisanje.
Preiavanje ili prerada Product Backlog-a podrazumeva dodavanje detalja, procena i promene
redosleda Product Backlog stavki. Ovo je trenutna aktivnost u kojoj Product Owner i Razvojni tim
sarauju na dodavanju detalja Product Backlog stavkama. Tokom prerade Product Backlog-a,
stavke se pregledaju. Scrum tim odluuje o tome kada je ova aktivnost zavrena. Preiavanje
obino ne zahteva vie od 10% kapaciteta Razvojnog tima. Product Backlog stavke ipak mogu biti
promenjene u bilo koje vreme od strane Product Owner-a.
Product Backlog stavke koje su u samom vrhu liste uobiajno imaju vie detalja nego one pri
dnu. Do preciznijih procena se dolazi s veim nivoem detalja i jasnoom; to je stavka nie u listi
obino ima vie detalja. Product Backlog stavke koje e zaokupiti Razvojni tim u narednom
Sprintu se prerauju na nain da se svaka od pojedinih stavki stvarno moe zavriti tokom
Sprinta, te se kao takve oznaavaju kao spremne (engl. ready) za odabir u narednom Sprint
Planning-u. Product Backlog stavke obino dobiju ovaj vid transparentnosti kroz gore navedene
aktivnosti preiavanja ili prerade.
Razvojni tim je odgovoran za sve procene (engl. estimates). Product Owner moe da utie na
Razvojni tim na nain da pomogne razumevanje zahteva i da razmatra razliite opcije, ali ljudi
koji implementuju moraju da daju konanu procenu.
Praenje napretka prema cilju
U bilo kojem trenutku, na putu ka uspostavljenom cilju, mogue je nai sumu preostalog posla.
Product Owner prati koliinu nezavrenog posla najmanje tokom svakog Sprint Review sastanka.
Product Owner poredi ovu koliinu sa iskustvima iz prethodnih Sprint Reviews kako bi pratio
napredak prema cilju u zadanom vremenskom okviru. Ove informacije su transparentne svim
zainteresovanim stranama.
Razliiti trending alati se mogu koristiti za predvianje napretka, poput tzv. burn-down ili burn-
up dijagrama. Oni su se pokazali korisnima, ali oni ipak ne zamjenjuju u potpunosti vanost
empirizma. U kompleksnim okruenjima ne zna se ta e se naredno desiti. Samo ono to se ve
desilo moe se koristiti za donoenje odluka koje se odnose na budunost.

1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 14
Sprint Backlog
Sprint Backlog je skup Product Backlog stavki koje su odabrane za odgovarajui Sprint, zajedno
sa planom o isporuci inkrementa proizvoda i ostvarenja Cilja Sprinta. Sprint Backlog je
predvianje Razvojnog tima o tome koje e funkcionalnosti biti u narednom inkrementu i koje
aktivnosti su potrebne da te funkcionalnosti budu smatrane zavrenima u inkrementu.
Sprint Backlog daje uvid u sve aktivnosti koje Razvojni tim identifikuje kao nephodne za
ostvarenje Cilja Sprinta.
Sprint Backlog je plan sa dovoljno detalja tako da se dinamika napretka moe pratiti kroz Daily
Scrum. Razvojni tim mijenja Sprint Backlog tokom Sprinta i on postaje sve jasniji kako Razvojni
tim poinje da implementira plan i ui vie o tome ta je potrebno implementovati da bi se
ostvario Cilj Sprinta.
Po potrebi, Razvojni tim dodaje nove aktivnosti u Sprint Backlog. Kako se odreene aktivnosti
zavravaju, preostali posao moe ponovno biti procenjen. Kada se utvrdi da odreeni elementi
plana nisu potrebni, oni se uklanjaju. Samo Razvojni tim moe da menja svoj Sprint Backlog
tokom Sprinta. Sprint Backlog je vidljiva i osveavana slika posla kojeg Razvojni tim planira
obaviti tokom Sprinta i pripada samo Razvojnom timu.
Praenje napretka u Sprintu
U bilo kojem trenutku tokom Sprinta, mogue je nai sumu preostalog posla u Sprint Backlog-u.
Razvojni tim prati ovaj preostali posao barem jednom dnevno tokom Daily Scrum brifinga kako
bi se mogla procijeniti vjerovatnoa ostvarenja Cilja Sprinta. Praenjem preostalog posla tokom
cijelog Sprinta, Razvojni tim moe upravljati svojim napretkom.
Inkrement
Inkrement je skup svih Product Backlog stavki koje su zavrene tokom Sprinta, zajedno sa
vrednou inkremenata iz svakog prethodnog Sprinta. Na kraju Sprinta, novi inkrement mora biti
zavren to znai da mora biti u upotrebljivom stanju i da ispunjava definiciju zavrenoga (engl.
Definition of Done) tog Scrum tima. Inkrement mora biti upotrebljiv bez obzira na to da li e ga
Product Owner dati u upotrebu ili ne.
Transparenstnost artefakata
Scrum se oslanja na transparentnost. Odluke o optimizaciji vrednosti i kontroli rizika zasnivaju se
na protumaenom stanju artefakata. Uz pretpostavku da je transparentnost potpuna, ove
odluke imaju dobru osnovu. Ali ako su artefakti samo delimino transparentni, odluke na osnovu
njih mogu biti pogrene, vrednost moe biti umanjena, a rizik povean.
Scrum Master mora da radi sa Product Owner-om, Razvojnim timom i drugim stranama da
razume da li su artefakti u potpunosti transparentni. Postoje odreene tehnike vezane za to
kako se tim treba nositi sa deliminom transparentnou; Scrum Master mora da pomogne
1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 15
svakome da provede odgovarajue aktivnosti kada transparentnost nije potpuna. Scrum Master
moe da uoi deliminu transparentnost pregledom artefakata, praenjem uzoraka, paljivim
sluanjem i uoavanjem razlika izmeu oekivanog i stvarnog rezultata.
Posao Scrum Master-a jeste da radi sa Scrum timom i organizacijom na poveanju
transparentnosti artefakata. Ovaj posao obino podrazumeva uenje, uveravanje i promenu.
Transparentnost ne dolazi preko noi, to je proces.
Definition of Done (definicija zavrenog)
Kada kaemo da je odreena Product Backlog stavka "zavrena" (engl. done), svako mora da se
sloi sa time ta to tano znai "zavrena". Premda definicija zavrenoga moe da varira meu
razliitim Scrum timovima, lanovi jednog Scrum tima moraju da imaju usklaeno razumevanje
definicije zavrenoga kako bi se obezbedila transparentnost. To je definicija zavrenoga ili
Definition of Done za Scrum tim i ona se koristi svaki put kada elimo da proverimo kada je
odreeni deo posla u inkrementu zavren.
Ista definicija slui kao vodilja Razvojnom timu tokom procene koliko Product Backlog stavki tim
moe odabrati tokom Sprint Planning-a. Svrha svakog Sprinta je dostaviti potencijalno isporuive
inkremente koji su uskladu sa vaeom definicijom zavrenoga tog Scrum tima.
Razvojni timovi isporuuju inkrement proizvoda svakog Sprinta. Ovaj inkrement je upotrebljiv
tako da Product Owner moe da odlui da li e ga odmah pustiti u upotrebu. Ako je definicija
zavrenoga deo dogovora, standarda ili vodia organizacije, svi Scrum timovi moraju da se prate
kao minimum zahtevanog. Ako definicija zavrenog nije deo dogovora na nivou organizacije,
Razvojni tim ili Scrum tim definie definiciju zavrenog koja odgovara datom proizvodu. Ukoliko
vie Scrum timova radi na sistemu ili proizvodu, Razvojni timovi svih Scrum timova moraju
zajedniki da dou do Definition of Done.
Svaki inkrement je nadogradnja na sve prethodne inkremente i detaljno je testiran kako bi se
obezbedilo da sve funkcionalnosti rade zajedno.
Kako Scrum timovi sazrevaju, oekuje se da se njihove definicije zavrenoga proire da ukljue
stroije kriterijume sa ciljem poveanja kvaliteta. Svaki proizvod ili sistem treba imati definiciju
zavrenoga kao standard za bilo koji rad koji se na njemu obavlja.

1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 16
Zavrna napomena
Scrum je besplatan i dostupan u ovom Vodiu. Scrum uloge, artefakti, dogaaji i pravila su
nepromjenjljivi i provoenje samo dela propisanog je mogue, ali to onda nije Scrum. Scrum
postoji samo u svojoj celosti i funkcionie kao okvir za druge tehnike, metodologije i prakse.
Zahvalnice
Ljudi
Od hiljade ljudi koji su doprineli Scrum-u, elimo da izdvojimo one koji su bili kljuni tokom prvih
deset godina. Pre svega to su Jeff Sutherland u saradnji sa Jeff McKenna-om, zatim Ken
Schwaber u saradnji sa Mike Smith-om i Chris Martin-om. Mnogi drugi su doprineli tokom
proteklih godina i bez njihove pomoi Scrum danas ne bi bio na ovom nivou.
Istorija
Ken Schwaber i Jeff Sutherland su zajedno prvi put predstavili Scrum na OOPSLA konferenciji
1995. Ova prezentacija je u sutini dokumentovala nalaze koje su Ken i Jeff sakupili tokom
prethodnih godina u primeni Scrum-a.
Smatra se da je istorija Scrum-a ve duga. U ast prvih koji su ga isprobali i nadogradili
izdvajamo: Individual Inc., Fidelity Investments, te IDX (dananji GE Medical).
Scrum Vodi dokumentuje Scrum kako je razvijan i odravan tokom vie od 20 godina od strane
Jeff Sutherland-a i Ken Schwaber-a. Drugi izvori vam obezbjeuju ablone, procese i iskustva
Scrum okvira. Oni optimizuju produktivnost, vrednost, kreativnost i ponos.

Prevod
Ovaj vodi je preveden sa originala na Engleskom jeziku, kojeg su obezbijedili Ken Schwaber i
Jeff Sutherland. Prevela Lidija Soro-Ricciardi.


1991-2013 Ken Schwaber i Jeff Sutherland, sva prava zadrana Str. | 17
ta je novo u Scrum Vodiu 2013 u odnosu na verziju iz 2011

1. Da bi mogli da se primjenjuju mehanizmi nadgledanja i poboljavanja, artefakti moraju
da budu transparentni. Ova verzija ukljuuje dodatnu diskusiju vezano za ovaj zahtev.
2. Dnevni Scrum je just-in-time dogaaj za planiranje u Scrum-u. Ulazna informacija je kako
tim napreduje ka ostvarenju Cilja Sprinta; izlaz treba biti novi ili pregledan plan koji
optimizuje napore tima ka ostvarenju Cilja Sprinta. Sve diskusije trebaju da budu u tonu
"mi, tim", a ne "ja, developer".
3. Sprint Planning je u ovoj verziji jedan dogaaj, za razliku od ranijeg dvofaznog planiranja
"ta/kako". Uspostavljanjem Cilja Sprinta zapoinje Sprint Planning tokom kojeg se zatim
uporeuje ta je sve potrebno za ostvarnje Cilja Sprinta uzimajui u obzir raspoloive
kapacitete i, konano, dogovarajui plan kojim e se tokom Sprinta ostvariti Cilj Sprinta.
4. Product Backlog se "prerauje" (engl. refining), a ne, kao ranije, "elja" (engl.
grooming). Preraene Product Backlog stavke su transparentne, razumljive i dovoljno
ralanjene da budu ulaz za Sprint Planning i da mogu da se odaberu za Sprint. Ovakve
transparentne Product Backlog stavke oznaavaju se kao "spremne" (engl. ready).
5. Svi dogaaji su vremenski ogranieni. Vremenska ogranienja u ovom Vodiu
predstavljaju gornju granicu. Sprint koji traje krae od mjesec dana najee ne zahteva
navedeno vreme.
6. Rezultat Sprint Review sastanka je potencijalno reorganizovan Product Backlog pri emu
se za naredni Sprint Planning najee biraju Product Backlog stavke najvie vrednosti.
7. Sprint Planning definie funkcionalnosti u planiranom inkrementu i planira kako e
Razvojni tim stvoriti taj inkrement. Cilj Sprinta treba da bude saetak rezultata ovog
rada.