Scrum

2. Ken Schwaber and Jeff
Sutherland, 2017
The Definitive Guide to
Scrum: The Rules of the
Game
Jeff Sutherland, 2014
Scrum- the art of doing
twice the work in half
the time
Jeff Sutherland, 2017
Penerbit Bentang Pustaka,
Scrum: Meningkatkan
Produktivitas Dua Kali Lipat
dalam Waktu Setengahnya
Saja
Joshua Partogi, 2015
Managemen Modern :
SCRUM #1

3. https://agiledigest.com/
https://www.scrumguides.org/ http://www.agilecampus.org/

4. •
•
•

8. Ada 3 alasan, mengapa software bisa
memiliki kualitas rendah, memiliki dirty
code dan tidak memiliki automated test.
1. Software developer tidak mengetahui teknik dan
praktik untuk mengembangkan sw berkualitas
tinggi
2. Software developer tidak diizinkan oleh
manajernya atau pelanggannya untuk
mengembangkan software berkualitas tinggi
karena mereka mengganggap hal tersebut
menyita waktu dan terlalu mahal untuk dilakukan
3. Software developer yang tahu mengembangkan
sw kualitas tinggi dan diiinkan oleh manager &
pelanggannya, namun tidak memiliki motivasi
untuk melakukannya.
• Banyak orang berfikir jika masalah
dalam proses software development
dapat dipecahkan dengan
meningkatkan kualitas teknologi.
• Permasalahan dalam software
development mungkin sebenarnya
adalah permasalah sosiologi bukan
masalah teknologi.
• Permasalahan terbesar dalam
software development adalah
interaksi manusia yang terlibat
didalamnya.

9. – Tantangan lebih kompleks
1. Tuntutan pengguna lebih tinggi
2. Jumlah pengguna lebih banyak
3. Tingkat kelihaian hackder sistem jauh lebihcanggih
4. Jumlah tim lebih banyak
5. Tingkat kerumitan teknologi lebih tinggi
6. Jumlah baris kode bertamah setiap harinya
7. Tingkat pengalaman dan keahlian orang yang menggunakan
teknologi tersebut juga bervariasi
8. 1 Developer tidak uup mengetahui satu bahasa
pemrograman, dev diharapkan untuk dapat menguasai
polygot programming. belum lagi user experience yang
semakin tinggi dari beragam karakter pengguna.
Tips Menjadi Polyglot Programmer
1.Kuasai Konsep dasar Pemrograman
1. Variabel dan Tipe data
2. Operator
3. Control Flow
1. Percabangan
2. Perulangan
4. Prosedur dan Fungsi
5. Penjebakan Error (Try/Catch)
6. Class dan Objek (OOP)
7. Menggunakan Library
8. Mengakses Jaringan (API, Web service, Soket, dll)
2.Kuasai dulu satu bahasa pemrograman secara mendalam
3.Berpikir seperti seorang Polyglot Programmer
1. Tidak ada yang instan
2. Berpikir terbuka dan tidak fanatik
4.Banyak-banyak latihan dan praktik
5.Baca tutorial, langsung coba
6.Tulis blog agar tidak lupa yang dipelajari
7.Ajari orang lain
Ref :
https://www.youtube.com/watch?v=mgf2ofYx8OE
https://www.quora.com/What-is-polyglot-programming
https://news.ycombinator.com/item?id=4748029
https://www.petanikode.com/apa-itu-polyglot-programmer/

15. Software development berbeda dengan proyek konstruksi. Setuju? Kalau kalian cuma bisa memilih
dua dari tiga dari time, scope dan quality, mana yang akan kalian pilih?
1. Time & Scope terpenuhi (DDD) tetapi kualitas buruk.
2. Time & Quality terpenuhi tetapi ruang lingkup dikurangi.
3. Scope & Quality terpenuhi tetapi waktu penyelesaian molor.

18. CREATE SOMETHING
TAKUT SALAH BUAT
TAKUT TIDAK
OPTIMAL
WATERALL
(OBVIOUS PROBLEM)
Big design dari awal
sampai akhir kayak
gedung
Solusi : project
manager, mandor –
planning as a plan as a
scope.
• Metodologi managemen proyek prediktif seperti
WATERFALL sangat cocok untuk domain masalah obvious
serta jenis pekerjaan yang bersifat prediktif dan repetitif
karena hubungan antara sebab dan akibat nya sudah jelas
• Dalam domain masalah obvious, perencanaan mula-mula
digambarkan lewat gantt chart dan work breakdown
structure. Hal ini sangat optimal jika tidak mengalami
perubahan selama proyek
• Jika perencanaan mulamula terlalu sering berubah, berarti
domain masalah anda sedang berada di domain
complicated atau bahkan complex

19. 1. Teknologi yang digunakan, meliputi :
• Seberapa banyak jenis teknologi yang
digunakan
• Seberapa rumit & kompleks teknologi itu
dipelajari oleh tim pengembang
• Jumlah baris kode yang ada didalam sw
hari ini
• Persentase perkembangan baris kode
setiap hari nya
• Kebersihan baris kode
• Seberapa sering teknologi tsb mengalami
diupdate oleh vendornuya
• Integrasi dengan sistem lain (platform &
teknologi yang berbeda)
• Dimana sistem akan dideploy: cloud atau
on promise
• Berapa banyak server yang digunakan
• Lokasi dan jumlah pengguna yang akan
mengakses sistem secara bersamaan.
2. Daftar keinginan product
owner untuk softwrae,
meliputi:
• Ketidakjelasan
desirement yang
diminta karena belum
pernah dibuat
sebelumnya oleh tim
dev
• Perubahan pasar begitu
cepat
• Profil pengguna yang
menggunakan software
• Bagaimana dan dimana
pengguna akan
menggunakan software
• Sistem birokrasi hierarki
perusahaan
• Regulasi pemerintah
• Kompetisi dan
kompetitor
• Kerumitan proses bisnis
dalam perusahaan
3. Orang yang terlibat di
pengembangan software.
Meliputi :
• Tingkat keahlian dan
pengalaman
• Tingkat kedewasaan
• Jumlah anggota
• Jumlah stakeholder
• Tingkat kekuatan politik
dan gaya memimpin
masing-masing stakeholder
• Distribusi lokasi
• Hubungan dan kontrak
antara pelanggan dengan
vendor software dev
• Gaya berfikir dan
kepercayaan
• Sifat psikologis orang yang
terlibat

20. CREATE SOMETHING
TAKUT SALAH BUAT
TAKUT TIDAK OPTIMAL
WATERALL
(OBVIOUS PROBLEM)
Big design dari awal
sampai akhir kayak
gedung
Solusi : project manager,
mandor – planning as a
plan as a scope.
AGILE using scrum
(COMPLEX PROBLEM)
Small designs validation
Iterative & prequent
Prototype-mvp
Design sprint
Self organize &
transparansi. Pembangun
sw
• Scrum menganggap memprediksi
masa depan adalah sebuah
kesiasiaan.
• Oleh karena itu scrum menggunakan
pengalaman masa lalu untuk
memproyeksikan masa depan.
• Scrum didasari oleh metode empiris,
3 hal yang menentukan keberhasilan
proses empiris :
1. Transaparansi (semua variabel yang
perlu dikatehui dibuat transparan
agar semua orang peduli)
2. Insepksi (Tinjau)
3. Adaptasi (iterasi adopsi)
• Tujuan akhir dari Agile Management
adalah “happiness”. Happy
customers dan Happy Employee.

21. • Scrum didasari oleh metode empiris
• Berbeda dengan metode prediktif
seperti metode waterfall yang
memastikan semua requirement
sudah jelas sebelum proyek dimulai,
dalam metode empiris kita tidak
berusaha mendetailkan semua
desirement karena masa depan tidak
dapat diprediksi
• Mendetailkan semua desirement
dalam lingkungan yang penuh
ketidakpastian menghabiskan banyak
waktu dan uang

22. 1. Di konsep management project tradisional,
kita biasanya mengestimasi keseluruhan
project di awal sehingga seorang PM bisa
mengatakan bahwa, okay this is perfect &
just stick to the plan. But...
2. Ada fundamental problem disini ketika
mengestimasi project dengan cara seperti ini,
yaitu cognitive biases yang berdekatan dengan
irrartional thinking sehingga memunculkan bad
judgement.
3. Masalah ini terdiri dari 2 hal, yakni Planning
Fallacy & Sunk cost & status quo bias
4. Solusinya adalah dengan scrum

23. Scrum sendiri dapat hidup didalam sebuah metodologi.
Scrum juga dapat digabungkan dengan teknik dan metode
pengembangan software dev lain. Oleh karena itu
membandingkan scrum dengan metodologi lain adalah
seperti membandingkan apel dengan jeruk.

28. • Tahukan kamu pekerjaan kamu bisa diselesaikan dengan setengah anggaran biaya
dalam waktu yang cepat? Scrum solusinya
• Scrum menggunakan metode perencanaan, pengerjaan, pengecekan dan tindak
lanjut.
• Kesalahan yang sering dilakukan banyak orang adalah pengecekan dan tindak lanjut
kerjaan dilakukan setelah kerjaan itu selesai.
• Hal ini menyebabkan adanya tekanan untuk jangan sampai salah.
• Dalam scrum, salah itu merupakan pembelajaran untuk memperbaikinya.
• Pengecekan dan tindak lanjut kerjaan dilakukan selama pengerjaan
• Ini mendorong adanya perbaikan sesegera mungkin ketika kesalahan sudah diketahui.
Plan do check act.
• Dengan begitu suatu kerjaan akan lebih cepat diperbaiki dan tidak perlu mengulang
pekerjaan dari awal.

29. http://www.scrumguides.org/scrum-guide.html

32. • Rancangan -> Sotware, dalam project
management traditional, kita kenal PM.
• PM (BOSS) = ada di awal rancangan sampai
sw itu benar-benar selesai.
• Dimanakah letak peran Project Manager
dalam Scrum? Scrum tidak mengenal peran
Project Manager karena dalam Scrum peran
tersebut redundan. Dalam Scrum, peran dan
tanggung-jawab Project Manager dipegang
bersama oleh Scrum Master, Product Owner
dan Development Team.
• Jumlah team scrum terdiri dari 3-9 orang agar
bisa bekerja efektif
PO = Product Owner
SM = Scrum Master
DT = Development Team
PM = Project Manager

33. • PO = tanggung jawabnya ada di zona rancangan, tidak
bertanggung jawab di zona pengembangan software
nya. PO memiliki hak veto terhadap rancangan
software seperti apa.
• DT = Bertanggung jawab terhadap pengembangan
software. DT membantu PO menerjemahkan
rancangannnya.
• SCRUM = bingkai kerja PO & DT
• SCRUM MASTER = Menegakkan bingkai kerja scrum
agar berjalan. Scrum master membantu DT
menyelesaikan masalah. SM tidak mesti pandai dari sisi
teknis, tapi dia bisa membuat DT bekerja lebih tangkas.
SM putus-putus = SM tidak bertanggung jawab atas
sebuah keluaran. Dia hanya bertnggung jawab pada
proses. PO & DT lah yang bertanggung jawab terhadap
sebuah keluaran software
PO = Product Owner
SM = Scrum Master
DT = Development Team
PM = Project Manager

34. Bertanggung jawab penuh atas keberhasilan rancangan sotware dimata user
1. Bertanggung jawab atas transparasi rancangan dia ke DT (untuk
keberhasilan komunikasi)
2. Seluruh pihak di organisasi (CEO, MANAGER, SEMUA CHIEP, DEVTEAM,
SCRUM MASTER) harus menerima keputusan akhir PO
3. Satu-satunya yang boleh mengarahkan waktu kerja DT. Kuncinya DT harus
fokus, karna sulit mengembangkan sw dalam waktu singkat.

35. 1. Bisa mengatakan ‘TIDAK’
• Product owner adalah seorang mini CEO
• Keputusan po sering kali di-override oleh CEO atau CTO perusahaan
• PO adalah seorang yang di-empower oleh para petinggi perusahaan dan
dipercaya untuk dapat mengambil keputusan untuk meningkatkan nilai
produk yang dia kelola
2. Memiliki Visi terhadap produk
3. Keahlian kewirausahaan. Orang yang menjadi PO biasanya berasal dari orang
bisnis
4. Memegang atau punya akses terhadap dana pengembangan produk
5. Berpikiran terbuka

36. 1. Terdiri dari para praktisi yang propesional
2. Karena berkewajiban menghasilkan updatean baru software yang siap dideploy ke user,
minimal setiap sprint (maks 1 bulan).
3. Bukan berarti di DT ini tidak boleh ada team yang baru belajar, tapi seluruh team harus
mampu BERKOMITMEN menyelesaikan seluruh rancangan yang ada di awal sprint.
4. DT harus lengkap memiliki semua keahlian hulu ke hilir sebagai satu tim. Mulai dari
rancangan bisnis sampai sotware yang siap guna ke user. (harus ada analys, programer,
designer, tester, dll). Mereka semua ini adalah developer(scrum meminta itu). Cross
function. Di 1 tim ada semua keahlian.
5. Punya hak penuh mengatur cara mereka DT bekerja. How to Build rancangan dari PO.
6. Berjumlah 3 sampai 9 orang
7. Push slow worker & and give congratulation the greatest worker
8. They are rockstar

37. 1. Software developer bukanlah
Resource
• Resource memiliki arti tempat atau benda
yang bisa dimanfaatkan sewaktu-waktu
bila dibutuhkan.
• Software dev diperlakukan sebagai
‘resource’ yang membebani perusahaan
sehingga harus dimanfaatkan semaksimal
mungkin.
• Software dev justru perlu dikembangkan
potensinya agar dapat meningkatkan bisnis
value bagi perusahaan
• Software developer lebih tepat disebut
KNOWLEDGE WORKER karena
menggunakan otaknya & knowledgenya
sebagai asset dalam bekerja bukan otot.
2. Tiga Motivasi intrinsik rockstar developer
• Visi yang jelas
Visi yang jelas menciptakan self direction. Fokus pada visi.
Jangan lakukan multitasking dalam pekerjaan. Orang yang
terlalu sering multi tasking akan tidak bisa fokus, cepat lupa,
& susah berkonsentrasi, tidak ada rasa memiliki dalam
pekerjaan & produk, dan orang tidak bisa menjadlin
hubungan yang baik dengan banyak orang.
• Self Management
Karena pada dasarnya manusia adalah makhluk yang liar,
bebal, tidak bisa diatur & memiliki otoritas yang tinggi
terhadap dirinya sendiri. Oleh karena itu scrum master
perlu mencoaching tim ini agar dapat self managing.
• Aktualisasi diri (self actualization)

38. 3. Hal yang salah kaprah terdapat software
developer
• Semua software developer itu sama
dan harus diukur
• Waktu software developer harus di
optimalkan hingga 100%
• Multitasking
• Respect my downtime
• Interupsi
• Able to work well underpressure
• Its overtime (lembur)
• Cari software developer yang
semurah mungkin
4. Prasyarat scrum development team
• Berfungsi antarlintas (cross functional) – rugby
team, jangan seperti management traditional
yang berjalan dengen melempar pekerjaan satu
sama lain.
• No superhero in tim, semuanya harus bekerja
bersama
• Mampu berkomunikasi dengan baik
• Proaktif dan tidak takut bertanya & meminta
bantuan
• Openmind & mau menerima pendapat orang
lain
• Mampu memberi saran dgn kalimat yang tidak
menghakimi
• Meaningfull conversation
• Shared goal

39. TEST
ENGINEER
mengembangkan
automated
testscript
USER
EXPERIENCE
(UX) DESIGNER
mengembangkan
user experience
WEB & UI
DESIGNER
mengembangkan
halaman website
(Frontend dev)
DATABASE
ADMINISTRATOR
mengembangkan
skema basis data &
stored procedure
BUSINESS
ANALYST
mengembangkan
executable documents
TECHNICAL WRITER
mengembangkan user
manual dan screencast
SOFTWARE
ENGINEER
mengembangkan
software dengan kode
yang bersih
SECURITY
ENGINEER
mengembangkan
sistem yang aman
BUILD &
DEPLOYMENT
ENGINEER (DEV
OPS) mengembangkan
automated build dan
automated deployment
SOLUTION
ARCHITECT
mengembangkan
arsitektur software

40. Apa itu scrum master berdasarkan Scrum Guide
Scrum master =
• Memastikan scrum itu dipahami dan dihidupi oleh tim scrum sesuai scrum guide
• Dia adalah servant leader, pemimpin yang melayani (Servant Leader).
• Mereka diluar team scrum, harus memahami interaksi mana yang bermanfaat dan mana
yang tidak. scrum master harus berani memastikan tim diluar scrum tidak mengganggu
tim scrum.
• Scrum master harus bisa membuat seseorang keep improving.
• Scrum master harus selalu bertanya dalam diri “Bagaimana saya dapat melayani orang-
orang didalam perusahaan lebih baik lagi dari kemarin agar seluruh potensi mereka keluar
dari dalam diri mereka”

41. 1. Scrum master adalah nama lain technical leader
2. Scrum master adalah customer proxy
3. Scrum master adalah nama lain dari manajer proyek
4. Scrum master adalah sekretaris pribadi untuk tim dev
5. Scrum master adalah Subject Matter Expert (SME)

45. Hal-hal yang harus diketahui scrum master, Based in scrum guide :
1.Scrum Guide Knowledge
DT mengambil jumlah kerjaan sendiri, tanpa ada intervensi dari siapapun ketika awal sprint. Ada pengontrol
Kualitas, Definition of done. Dev team bisa mengontrol sendiri standar minimum kualitasnya.
2. Teaching Skill, merupakan kemampuan menyusun materi ajar scrum
3. Process Managing Skill, merupakan Self Organize, Proses nya yang jadi inti nya. Scrum master tidak bertanggung
jawab pada keluaran program, tapi bertanggung jawab pada minimum proses itu berjalan. Scrum master harus dapat
mengencourage other to Team & Improve the process, harus dapat menumbuhkan rasa memiliki ke product ke
semua team scrum.
4. Retrospective Facilitator Skill, membantu mengarahkan orang-orang untuk perbaikan diri & perbaikan komitmen.
Bagian ini terdiri dari Continous Improvement Mindset (Jadikan spirit & semangatnya harus ada dalam diri scrum
master sebelum memberi motivasi ke pada orang lain), Emphiricms, pengetahuan hanya didapat oleh indera data
metric fokus, dan Discipline on retrospective, Scrum master harus pertama kali bertiindak ketika sesuatu yang buruk
terjadi dalam tim nya.

46. Hal-hal yang harus diketahui scrum master, Based in scrum guide :
5. Organization Influencing Skill, wajib untuk memastikan proses minimum berjalan. Scrum master tidak melakukan
locked deadline, Tidak ada deadline sesuai scope dan lainlain. Bagian ini terdiri dari:
a. Bird View, harus mampu melihat organisasi. Idea, idea solutif.
b. Contagious, berani untuk interupt
c. Persistance, ngotot ga ngeyel.
6. People Skill
a. Human Happiness
b. Conflict Mediation
c. Team Motivating

47. Untuk
PO,
Scrum
master
harus
Membantu memahami
perancangan produk ala
empirisme (bisa diukur &
fleksible diubah)
berdasarkan data nyata
dari pengguna. Bukan
perintah CEO.
Membantu terus mencari
teknik terbaik untuk
mengelola backlog (antrian
pekerjaan yang fleksible)
Untuk
DT,
Scrum
master
harus
Mempasilitasi praktik
scrum terlaksana untuk DT
yang baru mengenal
SCRUM
Membantu DT untuk
mengatur diri sendiri. SM
harus jadi inspirator DT
Bekerja iterative dalam
waktu yg singkat. Ini butuh
skill tinggi
Mendorong DT untuk selalu
memperbaiki cara kerja
dan kualitas sw buatan
mereka
Menghilangkan gangguan-
gangguan lain yang
menghambat mereka
namun diluar kendali DT
Untuk
ORGANISASI,
Scrum
master
harus
Bersama scrum master lain:
Memimpin dan
membimbing organisasi
dalam penerapan scrum
Membantu setiap pegawai
dan stakeholder untuk
memahami scrum
membantu membuat
perubahan di level
organisasi yang mendukung
tim scrum

48. • Scrum guide Tidak melarang
rangkap peran.
• Yang dilarang scrum guide hanya
rangkap peran PO dengan SM
• Scrum master adalah seorang ‘Master’ dalam scrum
• Scrum master adalah seorang partner. Scrum master akan berjalan disamping tim nya,
bukan hanya dalam keadaan senang, tapi juga dalam keadaan susah. Scrum master tidak
menghakimi timnya ketika mereka gagal atau khilaf
• Scrum master bukanlah orang yang ‘sok tahu’ hanya karena ia lebih berpengalaman
dibanding timnya.
• Scrum master menggunakan ‘artful questions’untuk memandu mencari jawaban itu
sendiri dan mencari teknik-teknik lain untuk memecahkan sebuah masalah.
• Scrum master tidak mengelola dan memberi instruksi kepada tim pengembang. Ia bahkan
tidak menugaskan orang-orang untuk mengerjakan sebuah pekerjaan.

49. SCRUM MASTER DI VIDEO INI LAKI-LAKI BERBAJU PUTIH ORANGE
GARIS-GARIS DENGAN TULISAN SCRUM-NL

51. 1.Product backlog
2.Sprint backlog
3.Potentially shippable product increment

52. 1. Adalah antiran pekerjaan (Feature a, b, c) yang dilakukan DT, bisa membuat
fitur, mebetulkan bugs, atau merapihkan kode. Ini sipatnya antrian.
2. Setiap pekerjaan itu dinamakan PBI, PRODUCT BACKLOG ITEM. (bagian dari
product backlog)
3. Informasi minimal, ditiap PRODUCT BACKLOG ITEM yang ideal :
1. Deskripsi
2. Urutan Stack
3. Nilai estimasi kesulitan
4. Estimasi Nilai bisnis
4. Product backlog
1. Nilai Estimasi kesulitan dikuasai DT
2. Sisasnya dikuasai PO (Desk, urutan, nilai bisnis)
5. Meski begitu, DT bisa membantu PO menuliskan deskpsi tersbut. PO hanya
via mulut,
6. KUNCI AGILE : PRODUCT BACKLOG = FLEKSIBLE (berubah ditengah
Berdasarkan data pengguna)
7. Multitaskting is not Good

53. • Product backlog item harus muat dalam 1 sprint, apabila
tidak muat, hendaknya dipecah agar muat dalam satu sprint
• Agar mudah dimengerti, buat product backlog item dalam
bentuk user story. Tim pengembang yang bertanggung jawab
untuk melayani product owner menuliskan PBI
• Scrum tidak mengenal change request karena segala bentuk
perubahan terhadap produk harus dimasukkan ke dalam
product backlog dan diurutkan kembali pengerjaanya.

54. Product backlog item (PBI) termasuk dan tidak hanya
terbatas dari:
1. Fitur baru
2. Technical design and specification
3. Defect
4. Non functional requirement
5. User interface mockup/wireframe
6. Enhancement
7. Beautification
8. Use case scenario
9. Acceptance criteria
10. Standard compliance
11. Customer support request

59. Story point : memberikan gambaran estimasi
seberapa lama suatu pekerjaan dibutuhkan
untuk diselesaikan.
Value point : seberapa penting sebuah task
untuk dilakukan
Pada agile estimasi, kit amembutuhkan
“DELIVER VALUE EARLY”
yang berisi 2 hal diatas
Gunakan konsep relative dari setiap tasknya

63. Pernyataan singkat mengenai pekerjaan yang
akan difokuskan dalam sebuah sprint

64. • Sprint adalah Fase-fase pengembangan yang singkat,
dimana didalamnya harus ada pengerjaan secara penuh.
(Analyze, design, integrate, test, build). Sprint backlog
adalah pekerjan disetiap 1 sprint.
• Sprint backlog Terdiri dari PRODUCT BACKLOG ITEM (PBI)
yang diambil dari PB & cara mengerjakannya (biasanya
terwujud dalam ‘tasktask’)
• Sprint backlog dikuasai sepenuhnya oleh DT
• Kecuali detail PBI yang PO luput dari sprint planning (artinya
SB fleksibel)
• Estimasi kesulitan PBI membantu DT melihat prporma
mereka dari sprint ke sprint
• TASK Biasanya ukurannya dalam JAM bukan HARI

66. 1. Individu memilih sendiri pekerjaan yang
ingin mereka lakukan
2. Pekerjaan tidak pernah ditugaskan pada
individu
3. Perkiraan sisa pekerjaan diperbaharui setiap
hari
4. Setiap anggota tim dapat menambahkan,
menghapus atau merubah sprint backlog
5. Pekerjaan baru dalam sprint akan muncul ke
permukaan
6. Apabila sebuah pekerjaan tidak jelas, buat
sebuah item sprint backlog yang baru
dengan durasi waktu yang lebih lama dan
dipecah di kemudian hari
7. Perbaharui daftar sisa pekerjaan ketika ada
pekerjaan yang telah diselesaikan
CONTOH SPRINT BACKLOG :

67. Bntukya sotware / user manual. Apapun yang bisa digunakan oleh user.
Kubus = sw, increment adalah potongan kecil dari kubus. Jadi increment user dapat
menggunakannya lgsg.
Incement membuat sw semakin lama semakin matang, kenaopa agile? Increment dibuat
berdasarkan respon terbaru dari penguna. Jadi kita benar-benar membuat sw yang sesuai dengan
maunya pengguna. ITULAH INDAHNYA AGILE

77. Kita mulai dari sprint planning, simplenya,
kita membuat sprin backlog & sprint goal
Peserta:
1. Semua tim scrum
2. Tenaga ahli (optional)
Masukkan (INPUT) Sprint planning,
sebelum alur dimulai :
1. Product backlog
2. Inkrement terbaru. Inkrement
sprint sebelumnya bisa dicoba
3. Rekam performa pengembangan.
Dokumen performa sprint sblmnya.

78. Alur
1. PO menjabarkan tujuan yang dia mau diawal
2. DT menjabarkan apa yang ingin mereka kerjakan
3. Lalu PO & DT berembuk bersama, menentukan
sprint goal, lalu mendetailkan PBI-PBI Terkait.
4. Fokus ke DT, DT mengambil jumlah pekerjaan (PBI)
untuk SPRINT BACKLOG yang visible dikerjakan 1
sprint(sanggup) (2minggu / 1 bulan). TIDAK ADA 1
ORANG PUN YANG BISA MENDIKTE DT untuk
mengambil jumlah kerjaan yang tidak mampu DT
kerjakan. DISINI DILAPANGAN SERING TERJADI
MEMBUAT DT bekerja lebih menderita. BAHAYA YA,
JANGAN.
5. Pendetailan PBI-PBI di SPRINT BACKLOG menjadi
plan (task) setidaknya garis besar. Minimal untuk
beberapa hari kedepan, yang jelas, detail HOW TO
nya bisa terus diubah dibeberapa hari kedepan.

79. Keluaran
1.Sprint Goal
2. Spring Backlog (PBI & PLAN)
• DARI SISI WAKTU, Scrum guide membuat sprint planning
punya batas waktu maksimum, SELESAI GA SELESAI, lewat
dari waktunya maks 8 jam untuk sprint selama 1 bulan.
• Karena kita berbicara tentang sprint backlog & berbicara
mengenai pendetailan produk backlog item sesuai arahan
PO, kita perlu membicaran DEFINITION OF DONE (DOD)
• Planning dilakukan berdasarkan fitur bukan aktifitas

80. SPRINT PLANNING REVIEW RETROSPECTIVE DAILY SCRUM
30 Hari 8 Jam 4Jam 3 jam 15 menit
3 minggu ~ 6 jam ~ 3 jam ~ 2 jam 15 menit 15 menit
2 minggu ~ 4 jam ~ 2 jam ~ 1,5 jam 15 menit
1 minggu ~ 2 jam ~ 1 jam ~ 45 menit 15 menit
Durasi masing-masing activity dalam scrum:

81. Pertimbangkan faktor-faktor berikut :
1. Seberapa mampu tim pengembang untuk menghantarkan production ready software. Beberapa tim
pengembang mungkin belum mahir untuk hal tersebut dalam waktu 2 minggu, sehingga 3 minggu atau sprint 1
bulan lebih cocok
2. Seberapa sering product owner ingin melihat perkembangan. Bagi beberapa product owner mungkin waktu 1
bulan terlalu lama
3. Seberapa sempat PO untuk hadir di sprint planning, sprint review, dan sprint retrospective. Bagi beberapa
product owner yang sibuk, mungkin bertemu dengan DT setiap 2 minggu sekali dirasakan terlalu banyak
4. Seberapa banyak item yang terdaftar di “DEFINITION OF DONE”. Bagi beberapa DT yang bekerja dibank, mereka
harus membuat banyak dokumentasi sehingga dalam 2 minggu mungkin belum dapat menghantarkan software
ready
Karena scrum menggunakan pendekatan BOTTOM-UP, yang dapat menjawab berapa durasi sprint yang ideal
hanyalah Product owner dan tim pengembang. Kedua pihak ini yang akan membuat kesepakatan mengenai durasi
sprint setelah mempertimbangkan semua faktor.

83. • Dod = ceklis prasyarat yang harus dilalui setiap PBI, tapi tidak
tertulis di deksripsi PBI, Syarat standar kena ke semua PBI &
DT.
• Versi minimum DOD adalah standar perusahan sendiri
• Maks DOD? Tidak ada, DOD adalah milik DT karena SB adalah
milik DT, Harus terus memperbaiki diri. DT boleh
menambahkan standar kualitas sw dia. BANYAK BANGET
EKSEKUSI DILAPANGAN yang membuat penggunaan SCRUM
menjadi sw yang tidak berkualitas. Karena dituntut dalam
waktu singkat, jadinya ada teknical dev issue. Solusinya jaga
oleh DEV OF DONE. Definisi dari selesai ditentukan bersama secara
konsensus
Contoh:
Telah di-deploy di local server oleh CI
Semua function telah melewati unit test
Semua fitur telah di-test oleh tester
Software sudah dalam bentuk releasable

84. 1. Code refactored, clean code all the time with low
cyclomatic complexity and high maintain ability index
2. All automated test script has been created with best
effort:
• Unit test script
• Integration test script
• Functional test script
• Performance test script
• Security test script
• Coded UI test script
3. Mission ciritcal business method are:
• Pair programmed
• Code reviewed by the whole team
• Covered by automated test and code coverage shoul
not be lower than 85%
4. No Compiler warning
5. Documentation has been created with best effort:
• User requirement specification
• User guide and user manual
• Architexture & texhincal specification
• Test scenario
• Functional test result
• Executale document that validate the code
6. All code are checked in and built by continouos build
7. Continuous build have build package to be runable inside
Docker
8. Sexy and clean UI/UX
9. Page loading time should not be more than 2 second
10. Manual functional testing and explanatory testing has
been done with best effort
11. Product owner can deploy the system with a single click
of a button with in release
12. We are proud to mention this software in our resume

85. • Sepanjang pengembangan:
• Sprint GOAL Tidak boleh berubah (Masalah besar untuk tujuan
bersama tidak boleh berubah)
• Plan pengerjaan boleh berubah, ga usah nunggu dari PO. DT boleh
mengubah cara how to mencapai tujuan.
• Terkait detail deskripsi PBI di SB bisa merubah (PB refinement)
• PB refinement bisa terjadi (seperti sprint planning PO & DT
berembuk untuk tujuannya untuk mempercantik, memperdetail &
memperjelas product backlog) secara adhoc(tidak bisa diduga)
ditengah2 (max. perubahan 10%)
• PBI di SB boleh berubah biasanya karena kendala teknis yg besar
atau instruksi darurat PO. Bisa ada PBI yang keluar

86. 1. Perubahan vs Kualitas
• Tujuannya bukanlah menghabiskan
banyak waktu untuk menciptakan
software dengan arsitektur
sempurna, namun menciptakan
sebuah software dengan arsitektur
yang dapat menerima perubahan
kapanpun juga
• DT perlu meningkatkan skillnya
dengan menerapkan design
principle dan design pattern yang
meastikan fw tetap berkualitas dan
feksibel terhadap perubahan
2. Test engineering vs click testing
• Seorang tester tidak boleh hanya dapat
melakukan ‘Click testing’ karena
siapapun dapat melakukan hal tersebut.
• Test engineering adalah aktifitas
mengembangkan automated test script
dan membangun infrastruktur untuk
automated test.
• TE bukan hanya mahir dalam test dari
tampilan sistem (black box testing),
namun harus mahir juga dalam internal
sistem test (whitebox testing)

87. 3. Executable documents not static
documents
• Tugas seorang bisnis analyst
adalah menerjemahkan
kebutuhan dari pihak bisnis
dalam bentuk dokumentasi
yang nantinya akan
diterjemahkan oleh
software engineer. BA harus
kolaborasi dengan test
engineer dan belajar
mengembangkan executable
document yang dapat
memvalidasi bisnis logic
4. Dirty Code
• Kode yang pertama kali
ditulis oleh software
engineer itu bagaikan
draft buku. Karena
masih draft. Maka kode
tersebut sifatnya masih
kotor.
• Sangat mungkin draft
kode ini memiliki
atribut berikut:
a) Method terlalu
besar dan
melakukan banyak
hal (God method)
b) Method dan class yang
susah untuk di unittest
c) Algoritma dan kode
yang masih di copy
paste dari sumber
diinternet
d) Class yang terlalu
panjang dan melakukan
banyak hal
e) Method yang berada di
dalam class yang salah
f) Algoritma yang masih
kompleks dan belum
efisien bila di ukur
dengan BIG-Onotation
g) Penamaan variabel,
class dan method yang
belum self explaining

88. 5. Nanti juga ada yang membersihkan
Dirty Code bersifat menular dalam tim dev yang tidak memiliki mental
profesionalisma. Perbedaan seorang software engineer yang profesional dengan
software engineer yang tidak dapat dilihat ketika mereka melihat sebuah kode
berjumlah 1000 baris sebelum menambahkan kode.
a) Software engineer yang tidak profesional akan menambahkan kode diatas kode
yang sudah berjumlah 1000 baris tersebut yang bisa menyebabkan kode melebihi
1000 baris
b) Software engineer yang profesional akan melakukan pairing dengan test engineer
untuk menuliskan unit test dan me-refactor kode yang berjumlah 1000 baris
tersebut sebelum menambahkan kode baru.

89. 6. Production Ready Software
• Dibutuhkan seorang software developer berkaliber
untuk dapat melakukan rilis product ready secara
konsisten di setiap sprint
• Kebanyakan software dev mengatakan kalau
production ready software adalah SUDAH DI TEST
& MEMENUHI ACCEPTANCE CRITERIA. Definisi ini
tidak dapat diterima karena untuk harus memiliki
standar tinggi terhadap software yang dibuat
dengan yang diberi nama DEFINITION OF DONE.
• Sebelum product development dimulai, Product
owner dan DT berkolaborasi mendefinsikan
“DEFINITION OF DONE” seperti contoh yang ada
pada slide DEFINITION OF DONE.
7. Yang penting jalan dulu deh
• Mental “yang penting
jalan dulu deh” tidak
memiliki kebudayaan
fanatisme terhadap
kualitas
• Managemen & pimpinan
perusahaan harus
menciptakan sebuah
lingkungan kerja dimana
kualitas menjadi budaya
perusahaan

90. Peserta :
Hanya DT
Penyelenggara (EO) :
Dev Team
Alur :
1. Masing-masing DT bergantian, tanpa diinterupsi harus lanjut, bercerita
1. Aktifitas kemarin (melakukan apa saja)
2. Kendala kemarin (internal, eksternal)
3. Rencana aktifitas hari ini apa saja. Ke 3 hal ini untuk membantu tim capai
sprint goal.
Penting untuk menyebarkan informasi pengembangan
2. Setelah daily scrum meeting ditutup, baru boleh rapat adhoc (terpisah)
3. Waktu maksimum 10-15 menit

91. Notes buat temen-temen :
perbedaan waktu kerja, lokasi kerja, budaya, bahasa dan kesibukan
aktifitas di setiap orang tidak menjadi halangan untuk melakukan daily
scrum ini. Karna kunci nya adalah komitmen & professional

93. AKTIFITAS SELAMA SPRINT
Business analyst akan mengembangkan executable document bersama test engineer, test engineer mungkin
sesekali waktu akan melakukan web deisng & mengembangkan user manual. Software engineer bisa duduk
bersama solution architect melakukan pairing untuk merancang arsitektur software bersama. Solution architect
bisa duduk bersama dengan security engineer untuk melakukan security testing & penetration testing. Kuncinya
adalah
DEVELOPMENT TEAM BEKERJA BERKOLABORASI & IMPROVISASI tanpa batasan dan urutan tertentu
DAN DI JAGA OLEH SEORANG SCRUM MASTER (dalam video : Wanita blazer hitam dan berkaos pink)

95. • Setelah dikerjakan increment
• Tujuannya untuk meninjau increment
• Peserta : PO & DT. Stakeholder terkait dan User
sample.
• Penyelenggara : PO mengundang
• Tujuan : meninjau increment dari DT ke PO &
memperbaharui PB.
• Waktu maks 4 jam untuk 1 sprint
• Alur :
1. PO yang punya acara, membuka dengan
menelaskan/menyatakan PBI mana yang sudah
selesai dan mana yang belum selesai
2. DT menjelaskan apa saja yang berjalan baik
sepanjang sprint, masalahnya seperti apa dan
pemecahan masalahnya seperti apa.
3. DT mendemonstrasikan inkrement (demo
produk)
4. PO mengulas keadaan pasar. (Analytic kita
begini, kompetitor kita begitu)
5. PB Refinement baru sembari tinjau hal hal
terkait perilisan produk, timeline, budget
potensi kapabilitas dan kondisi pasar

96. Activities :
Menginspect & mengadapt , meninjau dan mengadatasi proses
kerja DT
Peserta :
DT & SM
ALUR :
1. Ditinjau bagaimana sprint yang telah selesai berlangsung,
orangnya, hubungan antara orang, proses, dan perangkat kerja
2. Meninjau eksperimen perbaikan satu sprint ke belakang.
Adalah sebuah proses baru yang kita coba eksperiemtn 1
sprint. Ditentukan ekprerimen apa yang akan dikerjakan
ekpreimen selanjutnya. Bisa jadi eksperimen ini dilanjutkan ke
sprint selanjutnya.
3. Boleh memperbaharui DOD. Cth menambah jenis test di DOD
4. SM membuka wawasan DT terkait proses kerja (teknis,
nonteknis) boleh lewat referensi. Setidaknya bisa memberikan
pakar-pakar teknologi atau referensi buku.
Keluaran : Rencana implementasi perbaikan (improvement
experiment)
Waktu maks : 3 jam di 1 sprint
Catatan : Retrospecive adhoc diperbolehkan ditengah2 sprint.

105. • Dalam scrum, management risiko adalah dengan menghantarkan sesuatu yang
bernilai untuk pelanggan dalam jangka waktu sesingkat mungkin
• Apabila DT tidak bisa menghantarkan sesuatu yang bernilai bagi pelanggan dalam
jangka waktu 30 hari atau kurang, maka hal tersebut sudah merupakan resiko
tersendiri bagi pelanggan karena pelanggan secara eksponensial akan semakin
kehilangan kontak dengan pasar yang terus berubah.
• Model sprint menyediakan banyak opsi kepada pelanggan untuk dapat kompetitif di
pasar karena jangka waktunya yang singkat.
• Pelanggan akan lebih sering melihat perkembangan software developement dalam
bentuk product ready software.

106. 1. Scrum project meningkatkan kinerja secara
eksponensial dilihat dari aktifitas daily scrum
meeting dan end of each sprint yang
membutuhkan feedback untuk
menindaklanjutin pekerjaan agar lebih baik.
Dari sini bisa terlihat scrum melakukan twice
of work in half the time

107. 2. Adanya konsep 80/20 principle. 80% value
dapat dihasilkan dari 20% waktu project
keseluruhan. Hal ini menjadi pemicu yang
lebih cepat dengan kualitas yang baik untuk
dilakukan di sprint selanjutnya

108. 3. Sprint dalam scrum are constraint
with work hour, dalam scrum, kamu
akan melakukan catch up terhadap
kualitas pekerjaan setiap hari, jadi
akan terlihat hasil kualitas yang
semakin maksimal dibanding harus
melakukan work hour dengan project
traditional work yang dapat membuat
kualitas pekerjaan menurun

109. 1. Meningkatkan kualitas software
2. Mempercepat proses pengembangan dan penghantaran software
3. Menurunkan tingkat turnover dan meningkatkan tingkat kepuasan pegawai
4. Meningkatkan transparansi dalam perusahaan
5. Menghancurkan tembok pembatas penyebab birokrasi dan politik
6. Membentuk team culture of learning and continuous improvement (antistatus-
quo)
7. Meningkatkan sense of ownership setiap pegawai

110. 1. Cari satu alasan terkuat kenapa perusahaan anda harus berubah sekarang
2. Cari sponsor untuk dapat mendukung perubahan didalam perusahaan
3. Jelaskan kepada pimpinan kunci perusahaan lainnya untuk mengenal perubahaan
ini
4. Membuat sebuah aliansi untuk bersama-sama dapat membuat perubahan dalam
perusahaan
5. Buat dan urutkan product backlog untuk menuju perubahan ini
6. Edukasi dan empower pihak lain yang akan terlibat dalam perubahan
7. Review perubahan ini dan dampaknya terhadap perusahaan sebulan sekali
8. Scale out, make it persistent

113. Populate backlog dari semua fitur yang akan
kamu lakukan di project. Daftarkan semua backlog tersebut
kedalam format userstory. Semua task harus memiliki narasi
1. Siapa yang membutuhkan
2. Apa hal spesifik dibutuhkan
3. Dan kenapa dia membutuhkan itu
Setelah dibuat userstory, lalu prioritaskan product
backlog ini kedalam urutan pengerjaan berdasarkan
COSTUMER VALUE & IMMEDIATE IMPACT sesuai visi
product owner. Product owner & DT bisa mengisi
bagian ini.
Detail kan product backlog ini menjadi task-task yang
lebih rinci seperti proses analisis dokumentasi, desain,
code, test engingeering, integrasi, dll tanpa ada urutan
sekuensial pada masa developmentnya.

114. • Gunakan fibonacci sequence : 1,2,3,5,8,13,etc
• Jangan mengestimasi di kondisi yang pasti seperti jumlah jam
pengerjaan.
• Untuk mengimplementasikan relative estimae, mulai dari task
yang paling susah dan paing panjang pengerjaannnya. Lalu isi
task lain, dari relative ke yang paling susah
• Story point tidak mengukur kompleksitas, tapi mengukur
seberapa besar effort yang harus dilakukan

115. • Works sprint biasanya terdiri dari 1-2 minggu,
maksimal 1 bulan
• Dan goal nya adalah melakukan demo day di akhir
sprint
• Tentukan seberapa banyak point yang bisa kamu
selesaikan sampai ending sprint
• Misal setelah story point kita kalkulasi, plan awal
akan menghasilkan total 108 point, lalu setelah
pengerjaan sprint ini kita hanya mencapai 96 point.
Maka gunakan 96 point ini sebagai baseline di
sprint selanjutnya ditambahkan 10 % volume dari
task yang selalu sukses

116. • Buat scrum story board (misal di trello)
• Simple story board, hanya terdiri dari 3 kolom,
yaitu DO, DOING, DONE
• Populate task kedalam bentuk sticky notes dan
tempelkan
• Setiap hari kamu update task card ketika kamu
bekerja. Kemudian dokumentasikan kedalam
burndownchart.
• Burndownchart adalah chart sederhana yang
menunjukkan initial value storypoint yang bergerak
setiap harinya sampai end of sprint.
• Target harapannya dengan bundownchart ini
adalah di end of sprint memiliki nilai storypoint 0
(semua task yang diestimasi di awal selesai)

121. Feature list :
•Story Points: Set Story Points for
Trello Cards
•Effort completed: Set time spent on
tasks and remaining to check if your
team is still on track.
•Tags/Categories/Labels: Group
Cards into tags, User Stories or
projects, these are colored
automagically to save you time.
•Progress Bars: Visualize your Sprint
progress instantly with unobstrusive
background progress bars on both
cards and lists.
•Header Separators: Use header
separators to group cards inside lists.
•Variable font size: Cards with more
Story Points have a slightly increased
font size so you can distinguish bigger
from smaller tasks at a glance.
Add Story Points to a card by typing the number in parenthesis:
(3) Design new homepage header
Track time spent on each card:
(1/3) Design new homepage header
Add a Tag to a card by writing it in square brackets:
[dev] Implement Ads in footer
Create a Header Separator by creating a new card with three asterisks at the start and end:
*** Sprint 3 ***
Instructions

123. https://trello.com/b/zJsfh8jP/bantu-anak-asuh-apps
https://youtu.be/BuZyd9ewflQ

124. • Lakukan daily standup meeting sekitar 5 menit.
• DT membahas secara bergantian,
• Apa yang sudah dikerjakan kemarin
• Apa yang akan dilakukan hari ini
• Masalah apa yang terjadi selama pengerjaan
agar dapat dilakukan improvement
Jika ada problem yang butuh didiskusikan
bersama, maka dilakukan terpisah setelah daily
standup meeting

125. • Diakhir sprint lakukanlah demo Minimum valuable
productnya
• Bukan product secara keseluruhan, tapi fitur yang
paling penting yang dibutuhkan user
• Selama demo, kalian grab feedback terkait product
nya dari user/customer
• Customer disini harus berkomentar, apakah
mereka APPROVED dengan fiturnya atau they need
IMPROVED fiturnya.

126. • Kumpul bersama tim scrum
• Bahas hal-hal berikut,
• Apa saja hal yang baik selama sprint
ini?
• Apa saja hal yang kurang baik selama
sprint ini?
• Dan improvement apa yang harus
dilakukan agar kinerja bisa lebih
meningkat, efektif & efisien

127. Ketentuan :
• 1 kelompok diwakili 1
sampai 2 orang presenter
• Membawa laptop sendiri
untuk persentasi
• 1 kelompok persentasi
selama miniamal 3 menit
maksimal 10 menit
• Pastikan 10 menit
tersebut seluruh isi
persentasi selesai dibahas
dengan baik.
• Isi persentasi :
A. Judul tugas besar & team
B. Screenshot Trello kelompok
C. Paparkan Hasil berikut:
1. Product Definition
1. The Team
2. Definition of done
3. User Persona
4. Style Guide
5. Key Partner
6. Project Milestone
7. Nonfunctional Requirement
8. Resource Tutorial
2. Product Backlog (disertai epic & story point)
3. Sprint Goal
4. Sprint Backlog (disertai epic & story point)
5. Task to do, inprogress, to verify, done. Jika sudah
selesai semua task, simpan semuanya di done
(disertai epic, label, dan estimasi waktu,
screenshotkan push coding ke github)
6. Foto aktifitas daily scrum meeting
7. DEMO APLIKASI
8. Sprint review
1. Berisi inspect problem
2. Adapt solution
3. Market Condition update
9. Burndown chart
10. Retrospective analysis
1. What went well?
2. What could be improved?
11. Retropective actions
1. What to Stop Doing?
2. What to Keep Doing?
3. What to Start Doing?
12. PBI Refinement to next Sprint