1. SCRUM MASTER
ESSENTIALS
COURSE
ScrumMaster Essentials - autor Kemal Bajramovic licencirano sa Creative Commons Attribution-NoDerivs 3.0 Unported License Licenca dozvoljava
redistribuciju ovog djela, komercijalnu ili nekomercijalnu, dok god je djelo distribuirano nepromjenjeno, u svojoj cijelosti, sa navođenjem autora.

2. Trener
Kemal Bajramovid, dipl.ing.el.
• Certified ScrumMaster® (CSM)
• Certified Scrum Product Owner® (CSPO)
• IT manager, ADSBIH
• Predavač iz oblasti e-Uprave, javnih nabavki IT roba i usluga, elektronskih
javnih nabavki, agilnog razvoja infromacionih sistema i Scrum-a
Kontakt:
kemal.bajramovic@gmail.com
www.linkedin.com/in/kemal

3. Learning backlog = „agenda“
• Zašto agilnost?
• Scrum osnove
• Principi agilnosti
• Radionica: Šta su za nas
Scrum vrijednosti?
• Sprintovi
• Sistemski zahtjevi i
korisničke priče
• Više o Product Backlogu
• Procjena vremena i brzina
razvoja
• Radionica: Planning Poker
Game
• Product Owner detaljno
• ScrumMaster detaljno
• Razvojni tim detaljno
• Planiranje sprinta
• Izvršenje sprinta
• Review sprinta
• Retrospektiva sprinta
• Scrum real feel

4. Zašto ste vi ovdje?
• Povežite se sa nekim za brzi intevju (potražite osobu koju
najslabije poznajete)
• Pokušajte saznati svrhu dolaska te osobe ovdje. Neka
od pitanja sa kojima možete početi su:
– Zašto si ovdje?
– Šta tebe pokrede/tvoja strast u razvoju proizvoda?
– Šta te sprečava da budeš izvrstan?
– Šta je najpreče tvojim klijentima?
– Šta su tvoja najveda/najmanja očekivanja od ovog kursa?
– Ovo su samo primjeri, budite kreativni, osmislite svoja
pitanja!
• Jedno otkride po sticky-ju, pišite jasno, vizualizirajte
stav, otkrijte šta kažu, osjedaju, misle i rade

5. Zašto ste vi ovdje?
1) Pitaj+istraži i otkrij „zašto“
2) Ne koristi „obično“, traži
posebne slučajeve
3) Ohrabri pričanje priča
4) Traži nekonzistentnosti
5) Obrati pažnju na neverbalnu
komunikaciju
6) Ne boj se tišine
7) Ne odgovaraj na vlastita
pitanja
8) Postavljaj neutralna pitanja
9) Ne postavljaj binarna pitanja
10)Budi spreman za bilješke
Zašto si ovdje?
Šta tebe pokrede/tvoja strast u razvoju
proizvoda?
Šta te sprečava da budeš izvrstan?
Šta je najpreče tvojim klijentima?
Šta su tvoja najveda/najmanja
očekivanja od ovog kursa?
Ovo su samo primjeri, budite kreativni,
osmislite svoja pitanja!
Kako intervjuisati →
Pokušajte saznati svrhu
dolaska te osobe ovdje.
Jedno otkride po sticky-
ju, pišite jasno,
vizualizirajte stav,
otkrijte šta kažu,
osjedaju, misle i rade...

6. Empathy mapa
Empathy mapa je kolaborativni alat koji timovi mogu koristiti da steknu bolje razumijevanje
svojih klijenata/korisnika. Empathy mapa može predstaviti grupu korisnika/korisnički segment.

7. ZAŠTO AGILNOST?
agile
: sposobnost brzog i laganog kretanja
: brz, mudar, i pametan

8. Projekti propadaju!
“Da građevinski inženjeri prave zgrade na isti način na koji softwareski inženjeri prave sisteme,
prvi djetlid koji bi naletio bi predstavljao kraj civilizacije kakvu je poznajemo.”
Dr. Paul Dorsey
Top 10 Reasons Why Systems Projects Fail, Harvard Kennedy School
2004 2006 2008 2010 2012
Uspješni 29 % 35 % 32 % 37 % 39 %
Propali 18 % 19 % 24 % 21 % 18 %
Djelomično 53 % 46 % 44 % 42 % 43 %
Standish CHAOS report
Gartner, juni 2012

9. Kako razvijamo software?

10. „U našoj industriji, vrijednost
se mijenja jer, vrlo često,
klijenti ne znaju šta zaista
žele. Dodatno, jednom kad
vide novi software u akciji,
njihova vizija o tome šta žele
se bez izuzetka uvijek
mijenja.“
Implementing Lean Software Development: From Concept to Cash
Mary Poppendieck i Tom Poppendieck

11. Tradicionalni waterfall pristup
PRETPOSTAVKE
• Waterfall model pomaže da se
otkriju problemi u ranoj fazi
• Zahtjevi de biti jasno definisani i
nede se mijenjati
• Kako je sve dokumentirano, novi
član tima de lako razumjeti šta
treba da se uradi
• Developeri trebaju striktno
slijediti dizajn
REALNOST
• Ako se zahtjevi promjene,
waterfall nede raditi
• Nemogude je savršeno odraditi
bilo koju od faza modela
• Teško je procijeniti potrebne
resurse za bilo koju od faza

12. Generički agilni proces

13. Ključni pojmovi
• product backlog: Prioretizirana lista funkcionalnosti (PBI-Product Backlog
Items) koje treba razviti.
• iteracija: Zaokruženi razvojni ciklus fokusiran na obavljanje potrebnog posla
kako bi se proizveo upotrebljiv rezultat (PSPI – Potentially Shippable Product
Increment).
• samoorganizirajući tim: Grupa motiviranih individualaca, koji zajedno rade
ka ostvarenju nekog cilja, imaju sposobnost i autoritet da donose odluke i
spremno se prilagođavaju promjeni zahtjeva posla.
• krosfunkcionalni tim: Tim sastavljen od članova sa svim funkcionalnim
vještinama (kao što su UX dizajneri, developeri, testeri) i specijalnostima
potrebnim za obavljanje posla.
• planiranje iteracije: Vrijeme kada se agilni tim sastane da dogovori koji
podskup funkcionalnosti iz product backlog-a može isporučiti u iteraciji.
• retrospektiva iteracije: Provjeri-i-adaptiraj aktivnost na kraju iteracije koja
se odnosi na isporučeni inkrement proizvoda i sami agilni proces.

14. Vrste problema

15. Waterfall vs. Agilni pristup (1)
Waterfall Agile
Planiranje Dugoročno Kratkoročno
Udaljenost korisnika i developera Velika Mala
Vrijeme između specifikacije i implementacije Dugo Kratko
Vrijeme potrebno za otkrivanje problema Dugo Kratko
Rizici vezani za vrijeme implementacije projekta Visoki Niski
Sposobnost odgovora na promjene Loša Dobra

16. Waterfall vs. Agilni pristup (2)
OČEKIVANI PROIZVOD
OČEKIVANI PROIZVOD

17. Waterfall tok razvoja proizvoda
A
B
C
PLANIRANO
REVIDIRANO
Stejkholderi nisu sigurni
u sve funkcionalnosti proizvoda
Kako se proizvod razvija, razmišljanja
i ciljne funkcionalnosti se mijenjaju
Detalji se otkrivaju
u razvoju
Interne i eksterne snage vode
promjenama i poboljšanjima

19. Empirijski tok razvoja proizvoda
A
B
C
PLANIRANO
REVIDIRANO
Česte tačke provjere
(dnevne, sedmične, mjesečne)
Korisnički zahtjevi se
prikupljaju vremenom
Projekat se adaptira kako
bi zadovoljio poslovne potrebe
IDEALNO
Kako se proizvod razvija
prave se promjene kursa (plana)

20. Empirijski pristup
PLAN | ZAHTJEVI | DIZAJN | RAZVOJ | TEST | INTEGRACIJA
PLAN | ZAHTJEVI | DIZAJN | RAZVOJ | TEST | INTEGRACIJA
PLAN | ZAHTJEVI | DIZAJN | RAZVOJ | TEST | INTEGRACIJA
PLAN | ZAHTJEVI | DIZAJN | RAZVOJ | TEST | INTEGRACIJA
PLAN | ZAHTJEVI | DIZAJN | RAZVOJ | TEST | INTEGRACIJA
S
E
D
M
I
C
E

21. Pitanje
Za koju vrstu posla je Scrum najpogodniji?
Niskog rizika
Kompleksni
Unaprijed definisani
Jednostavni

22. SCRUM OSNOVE
“Pristup razvoju proizvoda kao u štafetnim trkama…može biti u suprotnosti sa željama za
maksimalnom brzinom i fleksibilnošdu. Umjesto toga, holistički ili ‘rugby’ pristup—gdje tim
pokušava da pređe put kao cjelina, dodajudi loptu naprijed-nazad—može bolje poslužiti
savladavanju današnjih zahtijeva.”
The New New Product Development Game, H. Takeuchi, I. Nonaka
„Agilni tim treba naučiti kako da rade zajedno ka ispunjenju svoga cilja. Oni ne izvode
slobodne udarce, ved dodaju software jedni drugima. Svaki član ima ulogu u pobjedi tima.“
Agile Coaching, R. Davies, L. Sedley

23. Scrum framework
• Nije standardizirani proces, ved okvir za način
organizacije i upravljanja poslom.
• Baziran je na skupu praksi, vrijednosti i
principa.
• Scrum prakse čine Scrum uloge, aktivnosti,
artifakti i njima pridružena pravila.

24. SCRUM PRAKSE
Uloge
Product Owner
Scrum
Master
Razvojni tim
Aktivnosti
Sprint
Planiranje
sprinta
Dnevni Scrum
sastanak
Izvršenje
sprinta
Sprint
review
Sprint
retrospektiva
Product backlog
grooming
Artifakti
Product backlog
Sprint backlog
PSPI
Pravila
Razna pravila

25. Scrum uloge

26. Product Owner
• Jedini autoritet koji odlučuje koje
funkcionalnosti de se kojim
redoslijedom implementirati
• Održava i komunicira sa svim
učesnicima jasnu viziju šta Scrum
tim pokušava postidi
• Odgovoran za uspjeh rješenja koje
se razvija (ili održava)
• Aktivno sarađuje sa ScrumMaster-
om i razvojnim timom i mora biti
dostupan da odgovore na pitanja
čim se ona postave

27. ScrumMaster
• Pomaže da svi uključeni razumiju i
prihvate Scrum vrijednosti, principe i
prakse
• Pomaže timu da riješi probleme i
poboljša vlastitu primjenu Scrum-a
• Štiti tim od vanjskih uticaja i preuzima
lidersku ulogu u uklanjanju
prepreka/poteškoda koje utiču na
produktivnost tima
• Nema kontrolni autoritet nad timom

28. Razvojni tim
• Raznolik, krosfunkcionalan skup
ljudi koji su odgovorni za dizajn,
razvoj i testiranje željenog
proizvoda
• Samoorganiziran u nastojanju da
na najbolji način postigne cilj
postavljen of Product Owner-a
• Zlatno pravilo: 5±2 članova tima

29. Pitanje
Ko je odgovaran za poslovnu vrijednost
koju isporuči Scrum tim?
ScrumMaster
Project menadžer
Sponsor programa
Product Owner

30. Diskusija
• Analizirajte video
• Zbog čega je došlo do razvoja lošeg
proizvoda?

31. Diskusija
• Analizirajte video
• Zbog čega je došlo do razvoja lošeg
proizvoda?

32. Scrum aktivnosti i artifakti

33. Product Backlog
• Funkcionalnosti, greške koje
treba popraviti, ispravke i
poboljšanja funkcionalnosti i sl.
pri čemu je najvrijedniji sadržaj
na vrhu, odnosno lista je
prioretizirana
• Konstantno evoluira tokom
cijelog projekta kroz proces
backlog grooming-a

34. Primjer product backlog-a
Stavka backlog-a Procjena
Omoguditi gostu da napravi rezervaciju 4
Kao gost, želim da otkažem rezervaciju 6
Kao gost, želim da promjenim datume rezervacije 6
Kao zaposleni u hotelu, mogu da pokrenem RevPAR izvještaje
(revenue-per-available-room)
15
Unaprijediti obradu grešaka 8
... 20
... 50
Kreirati prototip dvije verzije forme radi diskusije sa klijentom. 8
Riješiti issue HREV-347 4
....

35. Uređivanje product backlog-a
grooming
: voditi računa o izgledu; učiniti urednim.
: pripremiti za specifičnu poziciju ili svrhu.
refinement
: poboljšanje ili elaboracija.
: precizno definisanje, fina distinkcija.
• Stavke se mogu
kreirati, mijenjati i/ili
brisati
• Stavke (PBI) su
poredani po prioritetu
• Relativna procjena
veličine (poena, dana)

36. Sprint
• Vremenski ograničen, fiksni datumi
• Mora rezultirati opipljivom vrijednošdu
• Nema promjene cilja sprinta niti osoblja
dok sprint traje

37. Planiranje sprinta
• Identifikacija najvažnijeg podskupa stavki PB koji de se
implementirati u narednom sprintu
• Product owner i razvojni tim dogovaraju cilj sprinta
• Taskovi i pripadajude PB stavke čine sprint backlog

38. Sprint backlog
• Razvoj sprint backloga – tipično 2 sata po
sedmici sprinta
• Nekoliko pristupa razvoju sprint backloga

39. Izvršenje sprinta

40. Dnevni Scrum
1. Šta sam uradio od zadnjeg dnevnog scrum-a?
2. Šta planiram uraditi do sljededeg dnevnog scrum-a?
3. Koje prepreke ili smetnje me sprečavaju u radu?
Ovo nije izveštaj o statusu za ScrumMaster-a
To je informisanje među jednakima

41. Inkrement proizvoda
• Inkrement proizvoda je zadovoljio od
razvojnog tima usvojenu definiciju
završenog posla (Definition of Done)

42. Sprint review

43. Retrospektiva sprinta

44. Ključni pojmovi
• sprint: vremenski ograničeni ciklus sa fiksnim početkom i krajem koji
treba rezultirati nečim što je od opipljive vrijednosti za klijenta odnosno
korisnika;
• product backlog item: nove funkcionalnosti, ispravke postojedih
funkcionalnosti, greške koje treba popraviti, tehnička poboljšanja ;
• backlog grooming/refinement: razvoj product backlog-a na osnovne
prioretizirane funkcionalnosti (korisničke priče – user stories);
• planiranje sprinta: prva aktivnost svakog sprinta na kojem product owner
i razvojni tim pregovaraju koje funkcionalnosti (korisničke priče) de tim
realizirati u tom sprintu;
• forecast, commitment: proces odabira PBI od interesa za product owner-
a, za koje se tim obavezuje/predviđa da ih može razviti u sprintu
• dnevni scrum: sinhronizacijski dnevni događaj na kojem tim dobija
jasniju, vedu sliku razvojnog procesa u trenutnom sprintu
• PSPI: potencijalno isporučivi inkrement koji zadovoljava od tima
usvojenu definiciju završenog posla (Definition of Done)
• sprint review/demo: inspect-and-adapt funkcionalnosti
odnosno proizvoda
• sprint retrospektiva: inspect-and-adapt Scrum procesa

45. Pitanje
Kada je sprint završen?
Kada istekne vrijeme sprinta
Kada se svi taskovi urade
Kada svi PBI na koje se tim commit-ao
zadovolje usvojeni definition of done
Kada razvojni tim to odredi

46. Pitanje
Koja od sljededih tvrdnji je tačna za
prepreke/poteškode?
Tim ne treba koristiti dnevne Scrum sastanke za
prijave prepreka/poteškoda
Top prioritet ScrumMaster-a je da ukloni
prepreke/poteškode.
Spori server se ne smatra poteškodom.
Posao Product Owner-a je da uklanja prepreke i
poteškode na projektu.

47. Pitanje
Koja uloga je odgovorna za razvoj Product
Backlog-a u inkrementalne dijelove
funkcionalnosti?
Svih uključenih u projekta
ScrumMaster
Product Owner
Razvojni tim

48. Pitanje
Koja uloga de najvjerovatnije da prezentira
poteškodu u implementaciji sprint-a?
ScrumMaster
Razvojni tim
Stejkholderi
Product Owner

49. Izvor i povijest Scrum-a
• The New New Product Development Game, Hirotaka
Takeuchi i Ikujiro Nonaka, HBR 01/1986
• Prvi Scrum projekat, Jeff Sutherland, Easel Corp.1993
• Prva prezentacija Scrum-a, Sutherland, Schwaber,
OOPSLA, 1995
• Agile Manifesto, Beck et al., 2001
• Scrum Alliance, Schwaber, Cohn, Derby

50. VRIJEDNOSTI I PRINCIPI AGILNOG I
SCRUM RAZVOJA

51. Vrijednosti agilnog razvoja
Tražimo bolje načine razvoja softvera
razvijajudi softver i pomažudi drugima pri njegovom razvoju.
Takvim radom smo naučili da više cijenimo:
Ljude i njihove međusobne odnose nego procese i alate,
Upotrebljiv softver nego iscrpnu dokumentaciju,
Saradnju s korisnicima nego pregovaranje oko ugovora,
Reagiranje na promjenu nego ustrajanje na planu.
Drugim riječima, iako cijenimo vrijednosti na desnoj strani,
više vjerujemo u one na lijevoj.
www.agilemanifesto.org

52. Scrum vrijednosti
• Fokus. Kako se fokusiramo samo na par stvari u jednom
momentu, dobro radimo zajedno i proizvodimo odličan
posao. Ranije isporučujemo vrijednije dijelove proizvoda.
• Hrabrost. Kako ne radimo sami, osjedamo podršku i imamo
više resursa na raspolaganju. Ovo nam daje hrabrost da
odgovorimo na vede izazove.
• Otvorenost. Kako radimo zajedno, naučeni smo da kažemo
kako radimo i šta nam je na putu. Naučili smo da je dobro
iskazati brige kako bi se iste mogle adresirati.
• Posvećenost. Obzirom da imamo vedu kontrolu nad onim
što radimo, postajemo posvedeniji uspjehu.
• Poštovanje. Kako radimo zajedno, dijeledi uspjehe i
promašaje, poštujemo jedni druge i pomažemo drugima da
postanu vrijedni poštovanja.

53. Vježba
Mi vjerujemo u
fokus
hrabrost
otvorenost
posvećenost
poštovanje
pa demo
____________
____________
*nešto uraditi+.
____________
____________

54. Šta Agile nije?
• Nije srebreni metak ili magična prašina
• Nije jedna metoda ili okvir
• Nije set alata
Umjesto toga, agile je stanje svijesti (mindset) i
drugačiji način rada u cilju postizanja poslovne
vrijednosti što ranije.

55. Pitanje
Kako Agile Manifesto tretira planiranje?
Obavezan je ugovor o detaljnom Product Backlog,
prije nego se bilo koja stavka planira za iteraciju.
U agilnom projektu planiranje nije potrebno, jer
se projekat fokusira na trenutni status.
Prethodno planiranje i dizajn je neophodna faza
prije nego što razvoj može početi.
Adekvatan odgovor na promjene je važniji od
slijeđenja plana.

56. Pitanje
Kako Agile Manifesto tretira saradnju sa klijentom?
Potrebna je tijesna saradnja sa klijentom kako bi se
osiguralo da su sve očekivane funkcionalnosti
definisane prije faze razvoja.
Nužan je sistemski i česti feedback od klijenta.
Tim mora saopštiti klijentu koje de funkcionalnosti
razviti u narednom sprintu, i cilj tima u tom sprintu.
Konsenzus korisnika je potreban prije nego stavka uđe u
sprint.

57. SPRINTOVI

58. Ključno o sprintovima

59. Ključno o sprintovima:
Timeboxing
• Uspostavlja limit na posao u radu (WIP)
• Namede prioritetiziranje posla
• Demonstrira progres
• Izbjegava se nepotrebni perfekcionizam
• Motivira okončanje posla u radu
• Poboljšava previđanje

60. Ključno o sprintovima:
Kratko trajanje
• Jednostavnost planiranja
• Brzi feedback
• Ograničenje mogudih grešaka
• Bolji ROI
• Zadovoljstvo rada
• Česte tačke provjere

61. • Ritmičan rad
• Pojednostavljuje planiranje
Ključno o sprintovima:
Konzistentna dužina

62. • Uzajamno obvezivanje razvojnog tima i
Product Owner-a
• Pojašnjenja su poželjna,ali samo ako ne utiču
značajno na cilj
• Moguda terminacija sprinta
Ključno o sprintovima:
Nema promjene cilja

63. Ključno o sprintovima:
Završava u skladu sa Definition of Done
Definition of Done
Dizajnirano
Razvijeno
Testirano
Dokumentirano
Integrisano
Definition of Done
Dizajnirano
• Završeni mockupi
Razvijeno
• Kod u standardnom formatu
• Kod iskomentiran
• Kod provjeren
Testirano
• Item testiran
• Integracija testirana
• Višejezičnost testirana
Dokumentirano
• ...
Integrisano
• Na produkcijskom serveru
• 0 poznatih defekata

64. Pitanje
Šta definition of done pomaže timu da razvije?
Funkcionalnost proizvoda spremnu za testiranje
Analiziranu i dizajniranu funkcionalnost
Inkrement potencijalno isporučivog proizvoda
Funkcionalnost deploy-anu korisnicima koji
isporučuje poslovnu vrijednost

65. SISTEMSKI ZAHTJEVI I KORISNIČKE
PRIČE (USER STORIES)

66. Kako Scrum tretira korisničke zahtjeve?

67. Usmeni razgovor
• Usmeni razgovor je ključni Scrum alat koji
osigurava da su korisnički zahtjevi pravilno
prodiskutirani i komunicirani
• Prednost usmene komunikacije je high-
bandwidth informacija i brzi feedback
jeftinije i brže do uzajamnog razumjevanja u
odnosu na obimni SRS dokument
• Dvosmjerna komunikacija može izroditi nove
ideje o problemima i šansama
...naučili smo da više cijenimo:
Saradnju s korisnicima nego pregovaranje oko ugovora

68. Progresivno rafiniranje stavki
Sekvencijalni razvoj
• Svi korisnički zahtjevi su na
istom nivou detaljnosti
• Odobreni SRS dokument mora
imati sve zahtjeve specificirane
• Svi zahtjevi su istog prioriteta
• SRS dokument sastoji ogroman
broj stavki, trošak promjene je
veliki
• „Kompletiran“ SRS dokument
ne stimulira konverzaciju
Scrum razvoj
• Svi korisnički zahtjevi ne
moraju biti na istom nivou
detaljnosti
• Zahtjevi su prioretizirani, oni
koje demo odmah raditi su
manji i vrlo detaljni
• Primjenjujemo strategiju
progresivnog rafiniranja stavki
kako bi, u pravo vrijeme,
rastavili velike, slabo opisane
zahtjeve, u skup manjih,
detaljno opisanih stavki

69. Korisničke priče (User Stories)

70. Nivo detaljnosti korisničkih priča

71. Vježba
Šta je EPIC?
Šta je THEME?
Šta je USER STORY?

72. INVESTiraj u dobre korisničke priče
• Independent Nezavisne
• Negotiable Dogovorljive
• Valuable Vrijedne
• Estimatable Procjenljive
• Sized Appropriately Veličinom adekvatne
• Testable Testiranju pogodne

73. Prikupljanje korisničkih priča
• User-Story-Writing Workshop
• Story Mapping

74. VIŠE O PRODUCT BACKLOG-U

75. Product Backlog
Product Backlog Items (PBIs)
Nove funkcionalnosti
Potrebne promjene
Defekti
Tehnička poboljšanja
Prikupljanje znanja/informacija
PBI tip Primjer
Nove
funkcionalnosti
Kao student, želim da vidim svoje ocjene online tako da ne moram čekati naredni
dan da saznam. [Acceptance criteria:...]
Potrebne promjene Kao student, želim da se lista kandidata koji se pozivaju na usmeni ispit bude
sortirana po prezimenu umjesto po ocjeni sa pismenog ispita tako da lakše
pronađem svoje ime. [Acceptance criteria:...]
Defekti Popraviti grešku
Tehnička poboljšanja Migrirati bazu na MS SQL Server 2012.
Prikupljanje
znanja/informacija
Kreirati prototip dvije verzije forme radi diskusije sa klijentom.

76. Osobine dobrog Product Backloga
• Detailed appropriately
• Emergent
• Estimated
• Prioritized
just in time,
just enough

77. PB Grooming / PB Refining

78. Ko radi refinement?

79. Kada PB grooming?

80. Definition of Ready
Definicija PB Item-a spremnog za Sprint
Poslovna vrijednost je jasno artikulirana
Razvojni tim dovoljno dobro razumije detalje tako da može donijeti
informiranu odluku da li može implementirati PBI
Zavisnosti su identificirane i nema vanjskih uticaja koje bi zaustavile
implementaciju PB item-a
Tim je adekvatno popunjen da može završiti PBI
PBI je pocjenjen i dovoljno mali da se komforno može implementirati u
jednom sprintu
Kriteriji prihvatljivosti (acceptance criteria) su jasni i testabilni
Scrum tim zna kako demonstrirati PBI tokom Sprint review-a

81. Pitanje
Šta se dešava kada, u toku sprinta, Product
Owner identificira novi, važni PBI?
ScrumMaster ohrabruje razvojni tim da uključi
dodatnu stavku.
Tim radi prekovremeno da završi PBI u trenutnom
sprintu.
Product Owner dodaje novi PBI u Product
Backlog.
Razvojni tim de produžiti trajanje sprinta da bi
uključio novu stavku.

82. PROCJENJIVANJE PRODUCT
BACKLOG-A I BRZINE RAZVOJA

83. Odnos veličine, brzine i trajanja

84. Šta i kada mjerimo?

85. Procjenjivanje stavki PB
• Principi procjenjivanja (estimation)
– Timska procjena razvojnog tima
– Procjenjivanje nije obvezivanje
– Tačnost, ne pretjerana preciznost
– Relativno, a ne apsolutno procjenjivanje
• Jedinica mjere
– Story points reflektira kompleksnost i obimnost
posla

86. Tehnika procjenjivanja: Planning Poker
Planning Poker koncepti:
• Baziran na koncenzusu
• Odražava ekspertsko mišljenje
• Stimulira intenzivnu diskusiju
• Određivanje relativne veličine
• Tačno grupiranje stavki
• Promovira stečeno iskustvo u
procjenjivanju

87. Pravila igranja Planning Poker-a

88. Vježba: Planning Poker
• Pročitajte specifikaciju
• Razvijte Product Backlog
• Kreirajte podskup Product Backloga za prvi
release
• Procijenite veličine PB stavki u story points
• Uzmite referentni PBI veličine 2
• Razbijte PB stavku na taskove
• Procijenite ukupnu dužinu trajanja projekta

89. Brzina razvoja (Velocity)
• Velocity mjeri kvantitet (veličinu) a ne kvalitet
fukcija za Product Ownera (vrijednost)
• Procjena velocity-ja:
– Na osnovu historijskih podataka
– Sprint planning za jedan ili više sprint-ova (velocity
range)
• Povedanje velocity-ja

90. PRODUCT OWNER DETALJNO

91. Kontekst Product Owner-a
Product owner je opunomodena središnja tačka liderstva odgovorna za razvoj proizvoda.

92. Odgovornost Product Owner-a
• Upravlja ekonomskim aspektom projekta
• Učestvuje u planiranju
• Radi refinement product backlog-a
• Definira kriterije prihvatljivosti i testira ih
• Sarađuje sa razvojnim timom
• Sarađuje sa klijentima/korisnicima

93. Osobine Product Owner-a
Poznavanje
domena
Komunikacijske
vještine
Donošenje
odluka
Odgovornost
•Vizionar
•Razumije da se sve ne može
predvidjeti
•Ima poslovnu/domensku ekspertizu
•Ima dobre odnose sa stejkholderima
•Pregovarač/graditelj konsenzusa
•Dobar komunikator
•Jak motivator
•Ima mod da donosi odluke
•Spreman na teške odluke
•Odlučan i uporan
•Preispituje poslovnu vrijednost
•Preuzima odgovornost za proizvod
•Posveden i dostupan
•Ponaša se kao dio Scrum tima

94. Radni dan Product Owner-a

95. Ko bi trebao biti Product Owner?
Vrsta razvoja
Interni razvoj
Komercijalni
razvoj
Outsourced
razvoj
Kandidat za Product Owner-a
Predstavnik/korisnik iz odjela
koji de koristiti sistem.
Interni proxy za stvarne klijente
odnosno korisnike (product
manager, project manager).
Predstavnik/korisnik iz
organizacije koja plada rješenje i
koja de koristiti sistem.

96. Kada Product Owner treba znati redi
NE!
• Ja znam šta je najbolje za vas sindrom
• Sanjarski sindrom
• Dva kapetana na brodu sindrom
• Tech odluka bez biznisa sindrom
• Super inženjer sindrom
• Sindrom istraživača
• Nojev sindrom
• Vrati se kad bude gotovo sindrom
• Sindrom samoposluživanja

97. Pitanje
CEO traži od tima da doda korisničku priču u
trenutni sprint. Šta tim treba da uradi??
Tim dodaje korisničku priču u trenutni sprint i
izbacuje iz Product backlog-a priču slične veličine.
Informira Product Owner-a pa da on/ona raspravi
to sa direktorom.
Poštuje direktorov autoritet i dodaje priču u
trenutni sprint bez ikakvih prilagodbi.
Dodaje korisničku priču u sljededi sprint.

98. Pitanje
Šta Product Owner radi u toku sprinta?
Intervenira kada je potrebno kako bi osigurao
da tim radi održivom brzinom.
Pojašnjava zahtjeve i odgovara na pitanja.
Vodi tim u njegovom poslu.
Štiti tim i proces rada.

99. Pitanje
Tokom Sprint planning sastanka, Product
Owner…
Prezentira user stories koje bi volio da tim razvije u
sprintu.
Dijeli izabrane korisničke priče u specifične
taskove.
Određuje kako de tim implementirati posao.
Odlučuje koliko de priča biti isporučeno do kraja
sprinta.

100. Pitanje
Šta je tačno za ulogu Product Ownera na
dnevnom Scrum-u?
Product Owner prezentira dodatne promjene koje
tim mora absorbirati u sprintu.
Učešde Product Owner-a definira tim.
Product Owner daje instrukcije timu kako da
isporuči traženu funkcionalnost.
Product Owner osigurava harmonično izvršavanje
posla u skladu sa predviđenom brzinom razvoja.

101. Pitanje
Šta je od sljededeg dobra opcija u slučaju
preopteredenog Product Owner-a?
Ograničiti vrijeme koje Product Owner provodi sa
Scrum timom.
Podijeliti odgovornosti Product Owner-a i
distribuirati obaveze na više ljudi.
Pitati projekt menadžera da preuzme neke od
obaveza Product Owner-a.
Osloboditi Product Owner-a svih drugih obaveza.

102. SCRUM MASTER DETALJNO
“Nisam ovdje da vam riješim probleme; ja sam tu da pomognem da
riješite svoje probleme.”

103. Odgovornost Scrum Mastera
• Trener (Coach)
• Servant lider
• Procesni autoritet
• Štit protiv uplitanja
• Uklanja prepreke
• Agent promjene (change agent)

104. Osobine Scrum Mastera
• Posjeduje znanje
• Preispitivač
• Strpljiv
• Spreman na saradnju
• Zaštitnik
• Otvoren i transparentan

105. Radni dan ScrumMastera

106. Popunjavanje pozicije
• Ko bi trebao biti ScrumMaster?
• Da li je ScrumMaster full-time pozicija?

107. Pitanje
Koja tehnika pomaže ScrumMaster-u da olakša
komunikaciju tima i Product Owner-a?
Uči Product Owner-a o tehnologijama
primjenjenim u sprintovima.
Uči tim da razgovara računajudi na poslovne
potrebe i poslovne ciljeve.
Asistira u održavanju kolaborativnih sastanaka.
Sve pobrojane.

108. RAZVOJNI TIM DETALJNO

109. Odgovornost razvojnog tima

110. Karakteristike dobrog
razvojnog tima (1)
• Samoorganizirajudi
• Krosfunkcionalno raznolik i dovoljan
• T-vještine
• "Svi za jednog, jedan za sve" stav
• High-bandwith komunikacija

111. Karakteristike dobrog
razvojnog tima (2)
• Transparentna komunikacija
• Prave veličine
• Fokusiran i posveden
• Radi održivom brzinom
• Dugoročan

112. Vježba: Cijena multitaskinga
• Uzeti stranicu sa vježbom sa oznakom 1 i
pripremiti olovku
• Završiti zadatak, pogledati vrijeme na štoperici
• Upisati vrijeme na post-it
• Analizirati broj grešaka i dodati na post-it

113. Vježba: Cijena multitaskinga
• Okrenuti stranicu sa vježbom na list sa
oznakom 2 i pripremiti olovku
• Završiti zadatak, pogledati vrijeme na štoperici
• Upisati vrijeme na post-it
• Analizirati broj grešaka i dodati na post-it

114. Pitanje
Šta je karakteristika dobrog razvojnog tima?
Čeka dodjelu zadataka.
Samoorganizira se.
Traži upute za rad od ScrumMastera.
Svi članovi imaju sličan nivo tehničkih vještina.

115. Pitanje
Kada tim započne sprint, ko određuje kako
tim radi?
Tim lider.
Projekt menadžer.
ScrumMaster.
Tim.

116. Pitanje
Tokom dnevnog Scrum-a, Damir spomene da je našao
open source kod za koji misli da de riješiti jedan od
problema na kojem radi. Želi to odmah
implementirati. Koji je najbolji sljededi korak?
 Svim članovima tima se kaže da evaluiraju Damirovo
rješenje i daju report na sutrašnjem dnevnom Scrum-u.
 Nakon dnevnog Scrum-a, organizirati de se poseban
sastanak kako bi se prodiskutiralo open source rješenja.
 ScrumMaster kaže Damiru da pripremi primjer upotrebe i
prezentaciju za tim kako bi oni razmislili o korištenju tog
koda.
 Product Owner bilježi smetnju i riješava problem nakon
sastanka.

117. SPRINTANJE: PLANIRANJE SPRINTA

118. Aktivnosti u planiranju sprinta

119. Proces planiranja sprinta
Start
Odredi
kapacitet
tima
Rafiniraj cilj
sprinta
Izaberi PB
stavku
Stekni
pouzdanje
da se stavka
može završiti
Obvezi
vanje?
Commit na
priču
Kapaci
tet?
Finaliziraj
commitment
Da
Ne
Ne
Da

120. Određivanje kapaciteta tima
Član tima Dostupan dana Dani za druge
Scrum aktivosti
Sati po danu Dostupan sati
Senad 10 2 7-8 56-64
Zdravko 8 2 6-7 36-42
Ivana 9 2 6-7 42-49
Damir 9 2 2-3 14-21
Ukupno 148-176

121. Task plan

122. Pitanje
Šta je od sljededeg GLAVNA svrha Sprint
Backlog-a?
Da ScrumMaster može upravljati progresom
razvoja u toku sprinta
Da razvojni tim može upravljati satima utrošenim
na implementaciju taskova u sprintu
Da Product Owner razumije na šta se razvojni tim
obavezao u sprintu
Da tim može upravljati poslom tokom sprinta

123. SPRINTANJE: IZVRŠENJE SPRINTA

124. Aktivnosti u izvršenju sprinta

125. Sprint Burndown Chart
Taskovi D1 D2 ... ... D10 D11 D12 D13 D14 D15
Task 1 8 4 4 2
Task 2 12 8 16 11 8 4 2
Task 3 3 3 3 2 1
...4-29 177 160 111 98 76 45 33 19 8 8
Task 31 8 6 6 4 3 0
Task 32 16 10 8 4
Ukupno 200 175 134 113 93 55 57 33 19 12

126. Pitanje
Zašto bi Product Owner trebao prisustvovati
dnevnom Scrum sastanku?
Da kaže timu na kojim narednim taskovima da
radi i da updateuje Product Backlog
Da komentariše progres razvojnog tima
Da vidi kakav je progres napravljen i utvrdi dali je
timu potrebna pomod
Da se uvjeri da tim još uvijek ima pravi sprint cilj
kojem teži

127. Pitanje
Koji pristup je po Scrum-u, kada razvojni tim utvrdi
da de biti teško isporučiti bilo kakvu poslovnu
vrijednost do kraja sprint-a?
Tim sugeriše Product Owner-u da terminira sprint
Tim odmah eskalira problem prema menadžmentu
Zajedno sa Product Owner-om, fokusira se na to šta se
može uraditi i identificira način da isporuči neku
vrijednost do kraja sprinta
Produžava trajanje sprinta na par dana kako bi se
završio posao koji de proizvesti poslovnu vrijednost u
tom sprintu

128. SPRINTANJE: SPRINT REVIEW
„Sprint review sastanak je posebno vrijedan za razvojni tim jer
omogudava timu da direktno pokaže svoj rad i dobije priznanje za isti od
stejkholdera. Sastanak doprinosi razvoju timskog morala, motivirajudi tim
da nastavi proizvoditi kvalitetan proizvod.“
Agile Project Management For Dummies, M. Layton

129. Učesnici sprint review-a
Učesnik Opis
Scrum tim Product Owner, ScrumMaster i razvojni tim prezentiraju i
dobijaju feedback vezan za izvršenje sprinta i razvijeni
inkrement proizvoda.
Interni stejkholderi Vlasnici proizvoda i menadžeri u organizaciji trebaju vidjeti
progres u razvoju proizvoda iz prve ruke. Ako je u pitanju
interni razvoj, interni korisnici i subject matter eksperti bi
trebali biti prisutni.
Drugi interni timovi Sales, marketing, pravnici...po potrebi mogu dati neki svoj
specifični doprinos kao feedback na demonstraciju
inkrementa proizvoda.
Eksterni
stejkholderi
Eksterni korisnici, klijenti, partneri...mogu dati vrijedan
feedback Scrum timu i ostalim učesnicima sastanka.

130. Aktivnosti sprint review-a

131. SPRINTANJE: RETROSPEKTIVA
SPRINTA
Evo mede Edvarda, silazi niz stepenice, bup, bup, bup, lupa glavom o stube, spuštajudi se za
Kristoferom Robinom. To je — koliko on zna — jedini mogudi način da siđeš niz stepenice.
Katkada mu se, ipak, učini da mora postojati i neki drugi način, a on bi ga se ved dosjetio kad
bi barem na trenutak mogao prestati udarati glavom i mirno porazmisliti.
Nekad mu se opet učini da drugog načina nema i nema, i da tako naprosto mora biti.
Medo Winnie Zvani Pooh, A.Milne

132. Aktivnosti retrospektive sprinta

133. Pristup retrospektivi sprinta
• Postaviti atmosferu
– Blame-free okruženje, aktivna participacija
• Dijeliti isti kontekst
– Razviti timsku vs. više individualnih perspektiva
• Identificirati insight-e
– Šta smo dobro radili u sprintu što želimo nastaviti?
– Šta nije bilo dobro u sprintu što želimo prestati?
– Šta bi trebali početi raditi ili poboljšati?
• Odrediti akcije i zatvoriti aktivnost

134. Pitanje
Koja uloga treba da podrži (facilitate)
sastanak retrospektive sprinta?
Product Owner
ScrumMaster
Razvojni tim
Niko

135. Reel Scrum vježba
• Situacija
– Radite u kompaniji koja prelazi na Agile!
– Od vas se traži da proizvedete trominutni VIDEO sa ubjedljivom „zašto
agile“ porukom, koji de se prikazati svima u vašoj organizaciji.
– Od vas se traži da finalni video imati zaplet i rasplet, najmanje 3 scene,
ODLIČAN kvalitet, muziku u pozadini.
• Kontekst
– Samo-organiziran, krosfunkcionalan tim de razviti video u jednom ili
više sprintova.
– Cilj: Izbjegavajte rizik kasne integracije. (Taskovi de vjerovatno biti:
razvoj priče, određivanje uloga, razvoj skripte, video
editing,integracija...)
– Stil: komedija, drama, dokumentarac, horor...izaberite sami
• Proces
– Izaberite Product Owner-a i ScrumMaster-a u timu – npr. 2 min.
– Product Owner određuje ubjedljivu „zašto agile“ poruku – npr. 5 min.
– Diskusija zapleta i scenarija – npr. 15 min. (alat npr. Story Mapping)
– Scrum razvoj

136. Attribution i preporuka za čitanje
• Slajdovi u ovoj prezentaciji sadrže grafike iz
Visual AGILEexicon®, koji je zaštideno ime
Innolution, LLC i Kenneth S. Rubina.
• Visual AGILEexicon® je korišten i opisan u
knjizi: Essential Scrum: A Practical Guide to
the Most Popular Agile Process.
• Više o Visual AGILEexicon-u i njegovoj
dozvoljenoj upotrebi možete saznati na:
http://www.innolution.com/resources/visual-
agilexicon

137. Dodatne preporuke za čitanje
The Scrum Field Guide: Practical Advice for Your First Year
Mitch Lacey
Scrum Shortcuts without Cutting Corners:
Agile Tactics, Tools, & Tips
Ilan Goldstein
Software in 30 Days:
How Agile Managers Beat the Odds, Delight Their Customers,
And Leave Competitors In the Dust
Ken Schwaber, Jeff Sutherland

138. Dodatne preporuke za čitanje
User Stories Applied: For Agile Software Development
Mike Cohn
Agile Retrospectives: Making Good Teams Great
Esther Derby, Diana Larsen, Ken Schwaber
Succeeding with Agile: Software Development Using Scrum
Mike Cohn