Panduan Scrum
Rincian Panduan Scrum:
Aturan Main
Juli 2013
Dikembangkan & dikelola oleh Ken Schwaber dan Jeff Sutherland
Daftar Isi
Tujuan dari Panduan Scrum ........................................................................................................... 3
Definisi Scrum................................................................................................................................. 3
Teori Scrum .................................................................................................................................... 3
Tim Scrum....................................................................................................................................... 4
Product Owner ........................................................................................................................... 5
Tim Pengembang ........................................................................................................................ 6
Scrum Master ............................................................................................................................. 7
Acara-acara Scrum.......................................................................................................................... 8
Sprint .......................................................................................................................................... 8
Sprint Planning ........................................................................................................................... 9
Daily Scrum ............................................................................................................................... 11
Sprint Review............................................................................................................................ 12
Sprint Retrospective ................................................................................................................. 13
Artefak Scrum ............................................................................................................................... 14
Product Backlog ........................................................................................................................ 14
Sprint Backlog ........................................................................................................................... 15
Inkremen .................................................................................................................................. 16
Transparansi Artefak .................................................................................................................... 16
Definisi Selesai .......................................................................................................................... 17
Catatan Akhir ................................................................................................................................ 17
Penghargaan................................................................................................................................. 18
Orang-orang ............................................................................................................................. 18
Sejarah...................................................................................................................................... 18
Perubahaan Panduan Scrum 2011 ke 2013 .................................................................................. 19
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 2
Tujuan dari Panduan Scrum
Scrum adalah sebuah kerangka kerja untuk mengembangkan & mengelola produk kompleks.
Panduan ini berisi definisi dari Scrum. Definisi ini berisi peran-peran, acara-acara, artefak-artefak
dalam Scrum dan aturan main yang menyatukan semuanya. Ken Schwaber dan Jeff Sutherland
mengembangkan Scrum; Panduan Scrum ditulis dan disebarluaskan oleh mereka. Bersama-sama
mereka bertanggung-jawab terhadap Panduan Scrum.
Definisi Scrum
Scrum (kb): Sebuah kerangka kerja di mana orang-orang dapat menyelesaikan permasalahan
kompleks yang senantiasa berubah, di mana pada saat bersamaan menghasilkan produk dengan
nilai setinggi mungkin secara kreatif dan produktif.
Scrum bersifat:
●
●
●
Ringan
Mudah dipahami
Sulit dikuasai
Scrum adalah kerangka kerja proses yang telah digunakan untuk mengelola pengembangan
produk kompleks semenjak awal tahun 1990-an. Scrum bukanlah sebuah proses ataupun teknik
untuk mengembangkan produk; daripada itu, ini adalah sebuah kerangka kerja di mana di
dalamnya anda dapat memasukkan beragam proses dan teknik. Scrum akan mengekspos
pergerakan efektifitas manajemen produk dan praktik pengembangan yang sedang anda jalani,
dengan begitu anda dapat melakukan peningkatan.
Kerangka kerja Scrum terdiri dari Tim Scrum, serta peran-peran mereka di dalamnya; acaraacara; artefak-artefak; dan aturan-aturan. Setiap komponen di dalam kerangka kerja memiliki
maksud tertentu dan peran penting demi keberhasilan penggunaan Scrum.
Aturan main Scrum menyatukan acara-acara, peran-peran dan artefak-artefak, menjaga
harmonisasi dan interaksi antar setiap komponen. Aturan main Scrum dijelaskan di sepanjang
dokumen ini.
Detail mengenai penggunaan kerangka kerja Scrum bervariasi dan dijelaskan di luar dokumen
ini.
Teori Scrum
Scrum didasari oleh teori kontrol proses empiris, atau dengan kata lain, empirisme. Empirisme
menekankan bahwa pengetahuan berasal dari pengalaman dan pembuatan keputusan didasari
oleh pengetahuan yang telah dimiliki hingga saat ini. Scrum menggunakan pendekatan berkala
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 3
(iterative) dan bertahap (incremental) untuk meningkatkan prediktabilitas dan mengendalikan
resiko.
Ada tiga pilar dari setiap implementasi kontrol proses empiris yakni: transparansi, inspeksi dan
adaptasi.
Transparansi
Aspek-aspek penting dari proses yang berjalan harus dapat ditinjau oleh pihak-pihak yang
bertanggung-jawab terhadap hasilnya. Transparansi mengharuskan aspek-aspek tersebut
didefinisikan dengan standar yang sama, sehingga semua peninjau memiliki pemahaman yang
sama mengenai apa yang sedang ditinjau.
Sebagai contoh:
●
●
Istilah-istilah pada proses yang sedang digunakan harus dapat dimengerti oleh setiap
pihak; dan,
Setiap pihak yang bekerja dan pihak yang menerima hasil pekerjaan harus memiliki
pemahaman yang sama mengenai arti kata “Selesai”.
Inspeksi
Pengguna Scrum harus secara rutin meninjau artefak Scrum beserta perkembangannya agar
perubahan dapat terdeteksi. Peninjauan sehendaknya tidak terlalu sering sehingga dapat
menyebabkan terhambatnya pekerjaan. Peninjauan paling bermanfaat jika dilakukan secara
rutin, oleh peninjau yang kompeten, pada saat pekerjaan berjalan.
Adaptasi
Apabila peninjau mendapatkan satu atau lebih aspek dari proses mengalami deviasi di luar
batasan yang dapat diterima, hingga hasil akhirnya menjadi tidak dapat diterima, maka proses
atau materi yang diolah harus diatur ulang. Pengaturan ulang harus dibuat sesegera mungkin
untuk meminimalisir deviasi yang lebih jauh.
Scrum menyediakan empat acara formal, yang dibungkus di dalam Sprint, untuk inspeksi dan
adaptasi, sebagaimana dijelaskan di bagian Acara Scrum di dalam dokumen ini:
●
●
●
●
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Tim Scrum
Tim Scrum terdiri dari Product Owner, Tim Pengembang dan Scrum Master. Tim Scrum
mengatur diri mereka sendiri dan berfungsi antar-lintas. Tim yang mengatur dirinya sendiri
menentukan cara terbaik untuk menyelesaikan pekerjaannya, daripada diatur oleh pihak lain
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 4
yang berada di luar anggota tim. Tim yang berfungsi antar-lintas memiliki semua kompetensi
yang dibutuhkan untuk menyelesaikan pekerjaan, tanpa mengandalkan pihak lain yang berada
di luar anggota tim. Model tim di dalam Scrum dirancang sedemikian rupa untuk
mengotimalisasi fleksibilitas, kreatifitas dan produktifitas.
Tim Scrum menghantarkan produk secara berkala dan bertahap untuk memperbesar
kesempatan mendapatkan masukan. Penghantaran secara bertahap dari sebuah produk yang
“Selesai”, memastikan produk yang berpotensi dapat digunakan, selalu siap.
Product Owner
Product Owner bertanggung-jawab untuk memaksimalkan nilai produk dan hasil kerja Tim
Pengembang. Cara pelaksanaannya sangat bervariasi antar organisasi, Tim Scrum dan individu.
Product Owner merupakan satu-satunya orang yang bertanggung-jawab untuk mengelola
Product Backlog. Pengelolaan Product Backlog mencakup:
●
●
●
●
●
Mengekspresikan dengan jelas item Product Backlog;
Mengurutkan item di dalam Product Backlog untuk mencapai tujuan dan misi dengan
cara terbaik;
Mengoptimalkan nilai dari hasil pekerjaan Tim Pengembang;
Memastikan Product Backlog transparan, jelas, dan dapat dilihat semua pihak, dan
menunjukkan apa yang akan dikerjakan oleh Tim Scrum selanjutnya;
Memastikan Tim Pengembang dapat memahami item dalam Product Backlog hingga
batasan yang diperlukan;
Product Owner dapat saja mengerjakan pekerjaan-pekerjaan di atas, atau menyerahkan
pengerjaannya kepada Tim Pengembang, namun satu-satunya pihak yang bertanggung jawab
tetaplah Product Owner.
Product Owner adalah satu orang dan bukan berupa sebuah komite. Product Owner dapat
mengejawantahkan aspirasi dari komite ke dalam Product Backlog, namun mereka yang ingin
merubah prioritas item Product Backlog, harus melakukannya melalui Product Owner.
Agar Product Owner berhasil menjalankan tugasnya, seluruh organisasi harus menghormati
setiap keputusan yang ia buat. Keputusan dari Product Owner ini dapat dilihat dari isi dan
urutan Product Backlog. Tidak ada seseorang pun yang dapat memerintah Tim Pengembang
untuk mengerjakan kebutuhan lain selain Product Owner. Dan Tim Pengembang pun tidak
diperbolehkan untuk melakukan apa yang diperintahkan oleh pihak lain selain Product Owner.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 5
Tim Pengembang
Tim Pengembang terdiri dari para profesional yang bekerja untuk menghasilkan tambahan
potongan produk (selanjutnya disebut Inkremen) “Selesai”, yang berpotensi untuk dirilis di
setiap akhir Sprint. Hanya anggota Tim Pengembang yang mengembangkan Inkremen ini.
Tim Pengembang dibentuk dan didukung oleh organisasi untuk mengatur dan mengelola
pekerjaannya secara mandiri. Sinergi yang ada di dalam tim akan meningkatkan efisiensi dan
efektifitas dari Tim Pengembang secara keseluruhan.
Tim Pengembang memiliki karakteristik sebagai berikut:
●
●
●
●
●
Mereka mengatur dirinya sendiri. Tidak ada satu orang pun (bahkan Scrum Master) yang
memerintah Tim Pengembang bagaimana cara merubah Product Backlog menjadi
Inkremen yang berpotensi untuk dirilis;
Tim Pengembang berfungsi antar-lintas, sebagai sebuah tim, memiliki semua keahlian
yang dibutuhkan untuk menghasilkan produk;
Scrum tidak mengenal adanya jabatan tertentu untuk anggota Tim Pengembang selain
Pengembang, apapun pekerjaan yang dikerjakan oleh masing-masing anggota tim; tidak
ada pengecualian untuk aturan yang satu ini;
Tim Pengembang tidak mengenal adanya sub-tim yang dikhususkan untuk bidang
tertentu seperti pengujian atau analisa bisnis; tidak ada pengecualian untuk aturan yang
satu ini;
Anggota Tim Pengembang boleh memiliki spesialisasi keahlian dan fokus di satu area
tertentu, namun akuntabilitas dari hasil dari pekerjaan secara keseluruhan adalah milik
Tim Pengembang.
Ukuran Tim Pengembang
Jumlah anggota Tim Pengembang yang optimal adalah cukup kecil untuk dapat berkoordinasi
dengan cepat, dan cukup besar untuk dapat menyelesaikan pekerjaan dalam satu Sprint. Jumlah
anggota tim yang kurang dari tiga orang akan mengurangi interaksi dan akan menyebabkan
produktifitas yang rendah. Tim Pengembang yang kecil kemungkinan akan mengalami
kekurangan keahlian tertentu pada saat Sprint berjalan, yang pada akhirnya menyebabkan Tim
Pengembang tidak dapat menghasilkan Inkremen yang berpotensi untuk dirilis. Tim
Pengembang dengan jumlah anggota lebih dari sembilan orang membutuhan terlalu banyak
koordinasi. Tim Pengembang dengan jumlah anggota tim yang banyak, akan menimbulkan
terlalu banyak kompleksitas bagi proses yang berbasiskan empirisme. Product Owner dan Scrum
Master tidak termasuk dalam hitungan, kecuali mereka juga turut ikut mengerjakan pekerjaan
yang ada di Sprint Backlog.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 6
Scrum Master
Scrum Master bertanggung jawab untuk memastikan Scrum telah dipahami dan dilaksanakan.
Scrum Master melakukannya dengan memastikan Tim Scrum mengikuti teori, praktik, dan
aturan main Scrum.
Scrum Master adalah seorang pemimpin yang melayani Tim Scrum. Scrum Master membantu
pihak di luar Tim Scrum, untuk memahami apakah interaksi mereka dengan Tim Scrum
bermanfaat atau tidak. Scrum Master membantu setiap pihak untuk merubah interaksi-interaksi
yang tidak bermanfaat sehingga bisa memaksimalkan nilai yang dihasilkan oleh Tim Scrum.
Layanan Scrum Master kepada Product Owner
Scrum Master melayani Product Owner dengan berbagai cara yang mencakup:
●
●
●
●
●
●
Mencari teknik yang paling efektif untuk mengelola Product Backlog;
Membantu Tim Scrum untuk memahami pentingnya Product Backlog item yang jelas
dan padat;
Memahami bagaimana perencanaan produk pada lingkungan yang didasarkan
empirisme;
Memastikan Product Owner tahu bagaimana mengelola Product Backlog guna
memaksimalkan nilai dari produk;
Memahami dan mempraktikkan agility; dan,
Memfasilitasi acara-acara dalam Scrum bila dipanggil dan dibutuhkan.
Layanan Scrum Master kepada Tim Pengembang
Scrum Master melayani Tim Pengembang lewat berbagai cara yang mencakup:
●
●
●
●
●
Membimbing Tim Pengembang untuk dapat mengatur dirinya sendiri dan berfungsi
antar-lintas;
Membantu Tim Pengembang untuk membuat produk bernilai tinggi;
Menghilangkan hambatan-hambatan yang dialami oleh Tim Pengembang;
Memfasilitasi acara-acara dalam Scrum bila dipanggil dan dibutuhkan; dan,
Membimbing Tim Pengembang dalam suasana organisasi di mana Scrum belum
sepenuhnya diterapkan dan dipahami.
Layanan Scrum Master Service kepada Organisasi
Scrum Master melayani organisasi tempat dia berada lewat berbagai cara yang mencakup:
●
●
●
●
Memimpin dan membimbing organisasi dalam penerapan Scrum;
Merencanakan implementasi Scrum di dalam organisasi;
Membantu setiap pegawai dan stakeholder dalam memahami dan menggunakan Scrum
dan pengembangan produk dengan metoda empiris;
Membuat perubahan yang dapat meningkatkan produktifitas di dalam Tim Scrum; dan,
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 7
●
Bekerja bersama dengan Scrum Master lainnya guna meningkatkan efektifitas dari
pengaplikasian Scrum di dalam organisasi.
Acara-acara Scrum
Acara-acara wajib dalam Scrum dihadiri untuk menciptakan sebuah kesinambungan dan
mengurangi adanya acara-acara lain yang tidak tercantum di dalam Scrum. Setiap acara di dalam
Scrum memiliki batasan waktu, yang artinya selalu memiliki durasi maksimum. Pada saat Sprint
dimulai, durasinya tetap dan tidak dapat diperpendek maupun diperpanjang. Acara-acara
lainnya dapat diakhiri saat tujuan dari acara tersebut telah tercapai; memastikan waktu
digunakan secukupnya tanpa ada yang terbuang sia-sia di sepanjang proses.
Selain Sprint itu sendiri, yang memang merupakan kontainer dari acara-acara lain, setiap acara
dalam Scrum adalah sebuah kesempatan formal untuk meninjau dan merubah sesuatu. Acaraacara ini dirancang secara khusus untuk menciptakan tranparansi dan peninjauan sampai ke
tingkatan kritis. Tidak adanya pelaksanaan salah satu acara ini akan mengurangi transparansi
dan menghilangkan kesempatan untuk meninjau dan membuat perubahan.
Sprint
Jantung dari Scrum adalah Sprint, sebuah batasan waktu selama satu bulan atau kurang, di
mana sebuah Inkremen yang “Selesai”, berfungsi, berpotensi untuk dirilis dikembangkan. Sprint
biasanya memiliki durasi yang konsisten sepanjang proses pengembangan produk. Sprint yang
baru, langsung dimulai setelah Sprint yang sebelumnya berakhir.
Sprint memuat dan terdiri dari Sprint Planning, Daily Scrum, pengembangan, Sprint Review dan
Sprint Retrospective.
Pada saat Sprint:
● Tidak boleh ada perubahan yang dapat membahayakan tercapainya Sprint Goal;
● Kualitas dari Sprint Goal tidak boleh menurun;
● Scope dapat diklarifikasikan dan dinegosiasikan ulang diantara Product Owner dan Tim
Pengembang seiring dengan bertambahnya pengetahuan.
Setiap Sprint dapat dikatakan sebagai sebuah proyek dengan batasan waktu tidak lebih dari satu
bulan. Sama halnya dengan proyek, Sprint digunakan untuk menyelesaikan sesuatu. Setiap
Sprint memiliki definisi mengenai apa yang akan dikembangkan, sebuah disain dan perencanaan
yang fleksibel yang akan membimbing pengembangan, pekerjaan yang akan dilakukan dan hasil
dari produk.
Sprint dibatasi pada satu bulan kalender. Bila jangka waktu Sprint terlalu panjang, maka definisi
mengenai apa yang akan dibangun dapat berubah, kompleksitas dapat meningkat, dan resiko
dapat bertambah. Sprint meningkatkan prediktabilitas karena adanya peninjauan dan
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 8
pengadaptasian terhadap perkembangan, setidaknya setiap satu bulan sekali. Sprint juga
membatasi resiko biaya hingga satu bulan saja.
Membatalkan Sprint
Sprint dapat dibatalkan sebelum batasan waktu Sprint selesai. Hanya Product Owner yang dapat
membatalkan Sprint, walaupun keputusan yang dia buat mungkin saja dipengaruhi oleh para
stakeholder, Tim Pengembang, ataupun Scrum Master.
Sprint dibatalkan apabila Sprint Goal sudah tidak sesuai harapan mula-mula. Hal ini dapat terjadi
apabila arahan perusahaan berubah, atau bila kondisi pasar atau teknologi berubah. Pada
umumnya, Sprint harus dibatalkan apabila Sprint menjadi tidak masuk akal lagi apabila
dilanjutkan. Namun karena batasan waktu Sprint yang begitu singkat, pembatalan biasanya
jarang terjadi.
Ketika Sprint dibatalkan, item Product Backlog yang “Selesai” ditinjau kembali. Apabila hasil
pekerjaan dari Product Backlog tersebut berpotensi untuk dirilis, biasanya Product Owner akan
menerima hasil pekerjaan tersebut. Semua item Product Backlog yang tidak selesai, diestimasi
dan dimasukkan kembali ke dalam Product Backlog. Pekerjaan dalam Product Backlog yang
sudah selesai tersebut akan mengalami depresiasi nilai dengan cepat dan harus diestimasi ulang
sesering mungkin.
Pembatalan Sprint membuang banyak tenaga, karena semua orang harus menyusun kembali
kelompoknya dalam Sprint Planning baru untuk memulai Sprint baru. Pembatalan Sprint sering
menyebabkan trauma bagi Tim Scrum, dan sangat jarang terjadi.
Sprint Planning
Pekerjaan yang akan dilaksanakan di dalam Sprint direncanakan pada saat Sprint Planning.
Perencanaan ini dibuat secara kolaboratif oleh seluruh anggota Tim Scrum.
Sprint Planning dibatasi maksimum delapan jam untuk Sprint yang berdurasi satu bulan. Untuk
Sprint yang lebih pendek, batasan waktunya biasanya lebih singkat. Scrum Master memastikan
bahwa acara ini dilaksanakan dan setiap hadirin memahami tujuannya. Scrum Master
mengedukasi Tim Scrum untuk melaksanakannya dalam batasan waktu yang telah ditentukan.
Sprint Planning harus dapat menjawab pertanyaan-pertanyaan berikut:
●
●
●
Apa goal dari Sprint?
Apa yang dapat dihantarkan di dalam Inkremen sebagai hasil dari Sprint yang sedang
berjalan?
Apa yang perlu dilakukan untuk dapat menghantarkan Inkremen tersebut?
Topik Pertama: Apa yang dapat dilakukan di dalam Sprint ini?
Tim Pengembang bekerja untuk memperkirakan fungsionalitas yang akan dikembangkan pada
saat Sprint. Product Owner menjabarkan obyektif yang harus dicapai di Sprint ini dan item
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 9
Product Backlog mana, yang apabila bisa diselesaikan di Sprint ini, akan mencapai Sprint Goal.
Seluruh anggota Tim Scrum berkolaborasi untuk memahami pekerjaan di dalam Sprint.
Masukan dari acara ini adalah Product Backlog, Inkremen yang terakhir, proyeksi kapasitas Tim
Pengembang dalam satu Sprint, dan histori performa Tim Pengembang. Jumlah item yang dipilih
dari Product Backlog untuk Sprint sepenuhnya diserahkan kepada Tim Pengembang. Hanya Tim
Pengembang yang dapat menilai seberapa banyak item yang dapat diselesaikan di Sprint ini.
Setelah Tim Pengembang memperkirakan item Product Backlog yang akan selesai dan
dihantarkan dalam Sprint ini, Tim Scrum mulai membuat Sprint Goal. Sprint Goal dapat
menciptakan sebuah keselarasan di dalam pekerjaan Tim Pengembang, yang mungkin tidak
akan ada bila masing-masing anggota tim memiliki inisiatif sendiri-sendiri tanpa adanya tujuan
yang sama.
Topik Kedua: Bagaimana pekerjaan yang telah dipilih dapat diselesaikan?
Setelah Sprint Goal dibuat dan item Product Backlog dipilih, Tim Pengembang menentukan
bagaimana mengembangkan fungsionalitas ini menjadi sebuah Inkremen yang “Selesai” pada
saat Sprint. Item Product Backlog yang telah dipilih untuk Sprint ini beserta rencana sampai bisa
selesai dan dihantarkan disebut sebagai Sprint Backlog.
Tim Pengembang biasanya memulai dengan merancang sistem dan pekerjaan yang perlu
dilakukan untuk menjadikan Product Backlog menjadi Inkremen yang berfungsi penuh.
Pekerjaan yang dirancang mungkin akan memiliki ukuran atau estimasi yang berbeda-beda.
Walaupun demikian, jumlah pekerjaan yang direncanakan pada saat Sprint Planning cukup
banyak untuk dikerjakan selama satu Sprint. Pekerjaan yang direncanakan untuk hari-hari
pertama dari Sprint dibagi-bagi jadi bagian-bagian kecil pada akhir acara ini, biasanya dalam
satuan satu hari atau kurang. Tim Pengembang mengatur dirinya sendiri untuk mengambil
pekerjaan di dalam Sprint Backlog, baik pada saat Sprint Planning maupun sepanjang Sprint.
Pada saat Tim Pengembang membuat perencanaan, rencana tersebut selalu mengacu pada
Sprint Goal. Pada saat Sprint berjalan, pekerjaan yang harus dilakukan terkadang berbeda
dengan apa yang telah direncanakan oleh Tim Pengembang pada saat Sprint Planning. Tim
Pengembang akan berkolaborasi dengan Product Owner untuk menentukan cara terbaik untuk
merevisi perencanaan dengan tetap mencapai Sprint Goal. Sprint Goal menyediakan fleksibilitas
mengenai bagaimana fungsionalitas dapat diimplementasikan sebelum Sprint berakhir.
Product Owner dapat membantu mengklarifikasi item Product Backlog yang dipilih dan
membuat pengecualian. Apabila Tim Pengembang mengatakan mereka memiliki terlalu banyak
atau terlalu sedikit pekerjaan, mereka dapat menegosiasikan ulang item Product Backlog yang
telah dipilih dengan Product Owner. Tim Pengembang juga dapat mengundang pihak lain untuk
menghadiri acara ini guna memberikan masukan yang berhubungan dengan hal teknis ataupun
domain permasalahan.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 10
Di akhir Sprint Planing, Tim Pengembang sudah harus dapat menjelaskan kepada Product Owner
ataupun Scrum Master, bagaimana mereka berencana untuk bekerja sebagai tim yang mengatur
dirinya sendiri untuk menyelesaikan Sprint Goal, dan membuat Inkremen yang telah diantisipasi.
Sprint Goal
Sprint Goal adalah sekumpulan tujuan yang akan dicapai dalam satu Sprint sepanjang
pengimplementasian Product Backlog. Sprint Goal memberikan arahan bagi Tim Pengembang
mengapa mereka mengembangkan Inkremen dalam Sprint tersebut. Sprint Goal dibuat pada
saat Sprint Planning. Sprint Goal memberikan Tim Pengembang fleksibilitas terkait bagaimana
implementasi fungsionalitas di tengah Sprint. Item-item Product Backlog yang terpilih
menghantarkan pada satu fungsionalitas yang selaras. Di mana bisa berupa Sprint Goal itu
sendiri. Sprint goal bisa juga berupa fungsionalitas yang selaras apapun, yang pada akhirnya
membuat Tim Pengembang berkerja bersama alih-alih dengan inisiatif sendiri-sendiri.
Tim Pengembang berkerja dengan dipandu oleh Sprint Goal. Untuk memenuhi Sprint Goal,
mereka mengimplementasikan fungsionalitas & teknologi. Jika hasil kerja mereka ternyata
berbeda dengan yang mereka duga sebelumnya, mereka berkolaborasi dengan Product Owner
untuk menegosiasikan ruang lingkup dari Sprint Backlog pada suatu Sprint.
Daily Scrum
Daily Scrum adalah kegiatan dengan batasan waktu maksimum selama 15 menit agar Tim
Pengembang dapat mensinkronisasikan pekerjaan mereka dan membuat perencanaan untuk 24
jam ke depan. Hal ini dilakukan dengan meninjau pekerjaan semenjak acara Daily Scrum terakhir
dan memperkirakan pekerjaan yang dapat dilakukan sebelum melakukan Daily Scrum
berikutnya.
Daily Scrum dilaksanakan pada waktu dan tempat yang sama setiap hari untuk mengurangi
kompleksitas. Pada saat pertemuan, Tim Pengembang menjelaskan:
●
●
●
Apa yang sudah saya lakukan kemarin yang telah membantu Tim Pengembang mencapai
Sprint Goal?
Apa yang akan saya lakukan hari ini untuk membantu Tim Pengembang mencapai Sprint
Goal?
Apakah ada hambatan yang dapat menghalangi saya atau Tim Pengembang untuk
mencapai Sprint Goal?
Tim Pengembang menggunakan Daily Scrum untuk meninjau perkembangan menuju Sprint Goal
dan meninjau tren perkembangan menuju selesainya pekerjaan yang ada di dalam Sprint
Backlog. Daily Scrum mengoptimalisasi kemungkinan Tim Pengembang akan mencapai Sprint
Goal. Setiap hari, Tim Pengembang harus memahami bagaimana caranya agar mereka dapat
bekerja bersama sebagai tim yang mengatur dirinya sendiri, untuk menyelesaikan Sprint Goal,
dan membuat Inkremen yang sudah diharapkan di akhir Sprint. Tim Pengembang atau beberapa
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 11
anggota tim seringkali langsung bertemu setelah Daily Scrum untuk diskusi yang detail, atau
untuk pengadaptasian, atau perubahan perencanaan, sisa pekerjaan dalam Sprint.
Scrum Master memastikan pertemuan ini berlangsung, namun yang bertanggung-jawab untuk
melangsungkannya adalah Tim Pengembang. Scrum Master mengajarkan Tim Pengembang
untuk melangsungkan Daily Scrum tidak lebih dari 15 menit.
Scrum Master memastikan bahwa hanya anggota Tim Pengembang yang berpartisipasi pada
saat Daily Scrum.
Daily Scrum meningkatkan komunikasi, menghilangkan pertemuan-pertemuan lain,
mengidentifikasi hambatan untuk dihilangkan, mendukung pembuatan keputusan secara cepat
dan meningkatkan tingkat pengetahuan tim. Pertemuan ini adalah kunci dari proses peninjauan
dan pengadaptasian.
Sprint Review
Sprint Review diadakan di akhir Sprint untuk meninjau Inkremen dan merubah Product Backlog
bila diperlukan. Pada saat Sprint Review, Tim Scrum dan stakeholder berkolaborasi untuk
membahas apa yang telah dikerjakan dalam Sprint yang baru usai. Berdasarkan hasil tersebut
tersebut dan semua perubahan Product Backlog pada saat Sprint, para hadirin berkolaborasi
menentukan apa yang dapat dikerjakan di Sprint berikutnya, untuk mengoptimalisasi nilai
produk. Pertemuan ini bersifat informal, bukan merupakan status meeting, dan presentasi dari
Inkremen diharapkan dapat mengumpulkan masukan dan menumbuhkan semangat kolaborasi.
Ini adalah acara dengan batasan waktu maksimum selama empat jam untuk Sprint yang
berdurasi satu bulan. Untuk Sprint yang lebih pendek, batasan waktunya biasanya lebih singkat.
Scrum Master memastikan bahwa acara ini dilaksanakan, dan setiap hadirin memahami
tujuannya. Scrum Master mengedukasi Tim Scrum untuk melaksanakannya dalam batasan
waktu yang telah ditentukan.
Sprint Review mencakup elemen-elemen berikut:
●
●
●
●
●
●
Hadirin termasuk Tim Scrum dan stakeholder kunci diundang oleh Product Owner;
Product Owner menjelaskan item Product Backlog apa yang sudah “Selesai” dan apa
yang belum “Selesai”;
Tim Pengembang menjelaskan apa yang berjalan dengan baik sepanjang Sprint, masalah
apa yang mereka hadapi, dan bagaimana mereka menyelesaikan masalah tersebut;
Tim Pengembang mendemonstrasikan pekerjaan yang sudah mereka “selesai”-kan dan
menjawab pertanyaan-pertanyaan mengenai potongan tambahan produk;
Product Owner menjelaskan keadaan terakhir Product Backlog. Ia dapat
memproyeksikan tanggal perkiraan selesai produk (bila dibutuhkan);
Seluruh hadirin berkolaborasi membahas pekerjaan selanjutnya, dengan begitu Sprint
Review menyediakan masukan yang berarti bagi Sprint Planning berikutnya;
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 12
●
●
Ulasan mengenai keadaan pasar--atau kemungkinan potensi penggunaan produk--yang
telah berubah dan hal yang paling berharga apa yang harus dikerjakan berikutnya; dan,
Review timeline, budget, potensi kapabilitas dan marketplace untuk antisipasi rilis
produk.
Hasil dari Sprint Review adalah revisi dari Product Backlog yang mendefinisikan kemungkinan
item Product Backlog untuk Sprint berikutnya. Product Backlog dapat dirubah secara
keseluruhan sebagai tanggapan atas peluang-peluang baru.
Sprint Retrospective
Sprint Retrospective adalah sebuah kesempatan bagi Tim Scrum untuk meninjau dirinya sendiri
dan membuat perencanaan mengenai peningkatan yang akan dilakukan di Sprint berikutnya.
Sprint Retrospective dilangsungkan setelah Sprint Review selesai dan sebelum Sprint Planning
berikutnya. Ini adalah acara dengan batasan waktu maksimum selama tiga jam untuk Sprint
yang berdurasi satu bulan. Untuk Sprint yang lebih pendek, batasan waktunya biasanya lebih
singkat. Scrum Master memastikan bahwa acara ini dilaksanakan dan setiap hadirin memahami
tujuannya. Scrum Master mengedukasi Tim Scrum untuk melaksanakannya dalam batasan
waktu yang telah ditentukan. Scrum Master berpartisipasi sebagai rekan yang bertanggungjawab terhadap proses Scrum.
Tujuan dari Sprint Retrospective adalah:
●
●
●
Meninjau bagaimana Sprint yang telah selesai berlangsung, termasuk hal-hal yang
berkaitan dengan orang-orangnya, hubungan antara orang-orang, proses, dan
perangkat kerja;
Mengidentifikasi dan mengurutkan hal-hal utama yang berjalan baik, dan hal-hal yang
berpotensi untuk ditingkatkan; dan,
Membuat rencana implementasi, dengan tujuan peningkatan cara-cara kerja Tim Scrum.
Scrum Master mengedukasi Tim Scrum untuk membuat peningkatan akan kerangka kerja proses
Scrum, juga proses dan praktik pengembangannya, sehingga lebih efektif dan menyenangkan di
Sprint berikutnya. Pada saat Sprint Retrospective, Tim Scrum merencanakan cara untuk
meningkatkan kualitas dari produk, dengan merubah definisi dari “Selesai” sebagaimana
dibutuhkan.
Di akhir Sprint Retrospective, Tim Scrum harus dapat mengidentifikasi peningkatan-peningkatan
yang akan diimplementasikan di Sprint berikutnya. Mengimplementasikan peningkatan ini di
Sprint berikutnya, merupakan salah satu bentuk adaptasi dari hasil peninjauan Tim Scrum itu
sendiri. Walaupun peningkatan-peningkatan dapat diimplementasikan kapanpun juga, Sprint
Retrospective memberikan kesempatan formal untuk fokus pada peninjauan dan adaptasi.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 13
Artefak Scrum
Artefak Scrum merepresentasikan pekerjaan atau nilai, bertujuan untuk menyediakan
transparansi, dan kesempatan-kesempatan untuk peninjauan dan adaptasi. Artefak yang
didefinisikan oleh Scrum secara khusus dirancang untuk meningkatkan transparansi dari
informasi kunci, dengan begitu semua pihak dapat memiliki pemahaman yang sama terhadap
artefak.
Product Backlog
Product Backlog adalah daftar terurut, dari setiap hal yang berkemungkinan dibutuhkan di
dalam produk, dan juga merupakan sumber utama, dari daftar kebutuhan mengenai semua hal
yang perlu dilakukan terhadap produk. Product Owner bertanggung-jawab terhadap Product
Backlog, termasuk isinya, ketersediaannya, dan urutannya.
Product Backlog tidak pernah selesai. Pada awal pembuatannya hanya terjabar daftar
kebutuhan yang paling diketahui dan dipahami pada saat itu. Product Backlog berkembang
seiring dengan berkembangnya produk dan lingkungan di mana produk tersebut digunakan.
Product Backlog bersifat dinamis; senantiasa berubah agar produk dapat menjadi layak,
kompetitif di pasar, dan bermanfaat bagi penggunanya. Selama produk masih eksis maka
Product Backlog juga eksis.
Product Backlog menjabarkan semua fitur, fungsi, kebutuhan, penyempurnaan dan perbaikan
terhadap produk di rilis mendatang. Item Product Backlog memiliki atribut deskripsi, urutan,
estimasi dan nilai bisnis.
Seiring dengan digunakannya produk dan semakin bertambahnya nilai dari produk, dan
bertambahnya masukan dari pasar, Product Backlog semakin berkembang menjadi lebih besar.
Daftar kebutuhan tidak pernah berhenti berubah, sehingga Product Backlog dapat dikatakan
sebagai artefak yang hidup. Perubahan dalam kebutuhan bisnis, keadaan pasar, ataupun
teknologi dapat menyebabkan perubahan pada Product Backlog.
Tidak jarang ditemukan lebih dari satu Tim Scrum mengerjakan satu produk yang sama. Satu
Product Backlog digunakan untuk menggambarkan pekerjaan selanjutnya terhadap sebuah
produk. Bisa ditambahkan sebuah atribut, untuk mengelompokkan item Product Backlog.
Product Backlog refinement adalah kegiatan menambahkan detail, mengestimasi dan
mengurutkan item di dalam Product Backlog. Kegiatan ini berkesinambungan, di mana Product
Owner dan Tim Pengembang berkolaborasi untuk merinci item Product Backlog. Pada saat
Product Backlog refinement, item ditinjau-ulang dan direvisi. Tim Scrum sendiri yang
menentukan bagaimana dan kapan proses refinement diadakan. Refinement biasanya memakan
tidak lebih dari 10% kapasitas Tim Pengembang. Walaupun demikian, item Product Backlog
dapat diperbarui kapanpun juga oleh Product Owner--atau siapapun atas arahan Product
Owner--kapanpun ia mau.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 14
Item Product Backlog pada urutan yang lebih atas biasanya lebih jelas dan lebih detail
dibandingkan item di bawahnya. Estimasi dengan presisi tinggi diberikan berdasarkan tingkat
kejelasan dan detail yang tinggi; semakin bawah urutan dari item Product Backlog, maka
semakin rendah pula tingkat kedetailannya. Item Product Backlog yang akan dikerjakan oleh Tim
Pengembang untuk Sprint yang mendatang di-refine supaya setiap item yang dikerjakan dapat
di-“Selesai”-kan dalam satu Sprint. Item Product Backlog yang dianggap dapat di-“Selesai”-kan
oleh Tim Pengembang dalam satu Sprint dikatakan “Siap” untuk diseleksi pada saat Sprint
Planning. Item Product Backlog biasanya akan memiliki tingkat transparansi yang tinggi karena
adanya aktifitas refinement ini.
Tim Pengembang bertanggung-jawab terhadap seluruh estimasi. Product Owner dapat
mempengaruhi Tim Pengembang dengan cara membantu mereka memahami Product Backlog
dan membuat pengecualian terhadap Product Backlog, namun orang-orang yang akan
mengerjakan item Product Backlog-lah yang akan membuat estimasi final.
Memantau perkembangan menuju Sprint Goal
Di titik manapun, jumlah pekerjaan yang tersisa hingga akhir tujuan pengembangan dapat
dijumlahkan. Product Owner memantau total sisa pekerjaan ini setidaknya di setiap Sprint
Review. Product Owner membandingkan kondisi saat ini dengan jumlah sisa pekerjaan di Sprint
Review sebelumnya guna meninjau perkembangan menuju tujuan akhir dengan waktu yang
diharapkan. Informasi ini transparan untuk setiap stakeholder.
Berbagai macam praktik proyeksi terhadap trending telah digunakan untuk memperkirakan
kemajuan, seperti burn-down atau burn-up. Hal ini telah terbukti berguna. Namun hal ini tidak
menggantikan pentingnya peran empirisme. Di dalam lingkungan yang kompleks, apa yang akan
terjadi di masa mendatang tidak dapat diketahui sebelumnya. Hanya apa yang telah terjadi yang
dapat digunakan untuk membuat keputusan di masa mendatang.
Sprint Backlog
Sprint Backlog adalah sekumpulan item Product Backlog yang telah dipilih untuk dikerjakan di
Sprint, juga di dalamnya rencana untuk mengembangkan potongan tambahan produk dan
merealisasikan Sprint Goal. Sprint Backlog adalah perkiraan mengenai fungsionalitas apa yang
akan tersedia di Inkremen selanjutnya dan pekerjaan yang perlu dikerjakan untuk
menghantarkan fungsionalitas tersebut menjadi potongan tambahan produk yang “Selesai”.
Sprint Backlog menampilkan semua pekerjaan yang dibutuhkan untuk mencapai Sprint Goal
yang dibuat oleh Tim Pengembang.
Sprint Backlog adalah sebuah rencana yang cukup detail, di mana perubahan-perubahannya di
tengah Sprint bisa dipahami saat Daily Scrum Meeting. Tim Pengembang memodifikasi Sprint
Backlog sepanjang Sprint berlangsung, dan Sprint Backlog dapat berubah kapanpun juga
sepanjang Sprint. Perubahan ini terjadi seiring dengan berkerjanya Tim Pengembang sesuai
rencana pada saat itu, dan semakin meningkatnya wawasan tim untuk mencapai tujuan Sprint.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 15
Dengan bertambahnya pekerjaan baru, Tim Pengembang menambahkannya ke dalam Sprint
Backlog. Dengan dikerjakannya atau diselesaikannya pekerjaan, estimasi sisa pekerjaan juga
diperbaharui. Ketika ada elemen dari perencanaan tidak dibutuhkan lagi, maka elemen tersebut
dikeluarkan dari Sprint Backlog. Hanya Tim Pengembang yang dapat merubah Sprint Backlog
pada saat Sprint sedang berjalan. Sprint Backlog sangat transparan, menggambarkan secara
real-time pekerjaan yang akan diselesaikan oleh Tim Pengembang pada saat Sprint, dan ia
sepenuhnya menjadi milik Tim Pengembang.
Memantau perkembangan Sprint
Di titik manapun dalam Sprint, jumlah sisa pekerjaan dalam Sprint Backlog dapat dijumlahkan.
Tim Pengembang memantau sisa pekerjaan ini, setidaknya di setiap Daily Scrum, untuk
memproyeksikan kemungkinan mereka akan mencapai Sprint Goal. Dengan memantau sisa
pekerjaan ini sepanjang Sprint, Tim Pengembang dapat mengelola perkembangan pekerjaan.
Inkremen
Inkremen ( tambahan potongan produk ) adalah gabungan dari semua item Product Backlog
yang diselesaikan pada Sprint berjalan dan nilai-nilai dari Inkremen sprint-sprint sebelumnya.
Pada akhir Sprint, inkremen terbaru harus “Selesai”, yang artinya berada dalam kondisi yang
berfungsi penuh dan memenuhi definisi “Selesai” yang dibuat oleh Tim Scrum. Terlepas apakah
Product Owner akan merilis produknya, produk harus selalu berada dalam kondisi yang
berfungsi penuh.
Transparansi Artefak
Scrum berlandaskan transparansi. Keputusan-keputusan untuk mengoptimalisasi nilai produk
dan mengendalikan resiko dibuat berdasarkan keadaan artefak hingga saat ini. Pada titik di
mana transparansi berada pada tingkat tinggi, keputusan yang dibuat semakin dapat dipercaya.
Pada titik di mana transparansi berada pada tingkat rendah, keputusan dapat dimanipulasi, nilai
produk akan menurun dan resiko akan meningkat.
Scrum Master harus bekerja dengan Product Owner, Tim Pengembang dan pihak-pihak lain
untuk bersama-sama memahami apakah semua artefak sudah sepenuhnya transparan. Ada
banyak praktik untuk menangani belum penuhnya transparansi; dalam keadaan ini, Scrum
Master harus membantu semua pihak untuk menerapkan praktik yang sesuai terhadap
hilangnya transparansi. Scrum Master dapat mendeteksi hilangnya transparansi dengan
meninjau semua artefak, mengamati pola-pola yang terjadi, menyimak apa yang dikatakan, dan
melihat perbedaan antara apa yang diharapan dengan hasil yang sebenarnya.
Tugas Scrum Master adalah bekerja bersama Tim Scrum dan organisasi dimana ia berada untuk
meningkatkan tingkat transparansi dari artefak-artefak yang digunakan. Pekerjaan ini biasanya
membutuhkan pembelajaran, pendekatan persuasif, serta perubahan. Transparansi tidak terjadi
dalam semalam, melainkan sebuah perjalanan jangka panjang.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 16
Definisi Selesai
Ketika sebuah item Product Backlog atau Inkremen dikatakan “Selesai”, setiap pihak harus
mengerti dengan apa yang dimaksud dengan “Selesai”. Walaupun definisi ini berbeda-beda
antar tim Scrum, sesama anggota tim harus memiliki pemahaman yang sama mengenai
pekerjaan yang harus mereka selesaikan guna memastikan adanya transparansi. Ini adalah
definisi selesai untuk Tim Scrum dan ini digunakan untuk memeriksa apakah pekerjaan untuk
mengembangkan Inkremen dianggap selesai.
Definisi yang sama akan membimbing Tim Pengembang dalam mengetahui berapa banyak item
Product Backlog yang mereka bisa ambil pada saat Sprint Planning. Tujuan dari setiap Sprint
adalah untuk menghantarkan Inkremen, yang berpotensi untuk dirilis, yang memenuhi definisi
“Selesai” terkini yang dibuat oleh Tim Scrum.
Tim Pengembang menghantarkan Inkremen yang berfungsi setiap Sprint. Inkremen ini dapat
digunakan, supaya Product Owner dapat merilis produk tersebut sesegera mungkin jika ia mau.
Apabila definisi “Selesai” untuk sebuah Inkremen adalah bagian dari konvensi, standar atau
panduan pengembangan dari organisasi, setiap Tim Scrum harus mengikuti seluruhnya sebagai
minimum requirement. Apabila “Selesai” untuk sebuah Inkremen bukan merupakan bagian dari
konvensi, standar atau panduan pengembangan dari organisasi, Tim Pengembang harus
membuat definisi “Selesai” yang pantas untuk produk yang dikembangkan. Apabila ada
beberapa Tim Scrum yang mengembangkan sistem atau produk yang sama, seluruh Tim
Pengembang di setiap Tim Scrum harus menentukan definisi selesai yang sama bersama-sama.
Setiap Inkremen merupakan gabungan dari Inkremen Sprint-sprint sebelumnya dan diuji secara
teliti, untuk memastikan setiap Inkremen dapat berfungsi secara penuh.
Seiring dengan bertambah dewasanya Tim Scrum, mereka diharapkan untuk membuat definisi
selesai yang lebih baik dan ketat lagi demi peningkatan kualitas. Produk atau sistem manapun
harus memiliki definisi “Selesai” yang merupakan sebuah standar untuk pekerjaan yang akan
dilakukan.
Catatan Akhir
Scrum bersifat gratis dan disediakan di panduan ini. Peran, artefak, acara dan aturan dalam
Scrum tidak dapat dirubah dan walaupun penggunaan Scrum secara sebagian sangat
memungkinkan, hasilnya bukanlah Scrum. Scrum ada karena seluruh komponen ini dan
berfungsi dengan baik sebagai pembungkus untuk teknik, metodologi maupun praktik lain.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 17
Penghargaan
Orang-orang
Dari ribuan oang yang telah mengkontribusi terhadap Scrum, kami harus menonjolkan satu-satu
orang-orang yang memberikan kontribusi di sepuluh tahun pertama perkembangan Scrum.
Pertama Jeff Sutherland yang bekerja dengan Jeff McKenna, dan Ken Schwaber yang bekerja
dengan Mike Smith dan Chris Martin. Ada banyak pihak juga yang telah memberikan kontribusi
terhadap Scrum setelah itu dan tanpa mereka Scrum tidak akan mengalami penyempurnaan
seperti hari ini.
Sejarah
Ken Schwaber dan Jeff Sutherland pertama kali mempresentasikan Scrum di konferensi OOPSLA
pada tahun 1995. Presentasi ini pada dasarnya mendokumentasikan pembelajaran yang Ken dan
Jeff dapatkan setelah beberapa tahun menggunakan Scrum.
Sejarah Scrum sendiri termasuk cukup panjang. Untuk menghormati tempat-tempat awal Scrum
digunakan dan disempurnakan, kami tidak dapat melupakan Individual, Inc., Fidelity
Investments, dan IDX (sekarang GE Medical).
Panduan Scrum mendokumentasikan Scrum sebagaimana dikembangkan dan dipertahankan
oleh Jeff Sutherland dan Ken Schwaber selama lebih dari 20 tahun. Sumber lain akan
menyediakan pola, proses dan pengetahuan yang mendukung kerangka kerja Scrum. Hal ini
dapat mengoptimalisasi produktifitas, nilai, kreatifitas dan rasa bangga.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 18
Perubahaan Panduan Scrum 2011 ke 2013
1. Artefak harus transparan agar mekanisme peninjauan dan pengadaptasian dari Scrum
bisa efektif. Diskusi lebih lanjut dari kebutuhan ini sudah ditambah.
2. Daily Scrum hanya sebuah acara perencanaan singkat pada Scrum. Masukannya
seharusnya adalah tentang bagaimana keadaan tim dalam mencapai Sprint Goal;
keluarannya seharusnya adalah rencana baru yang akan lebih mengoptimalkan usaha
tim dalam mencapai Sprint Goal. Semua percakapan cenderung menggunakan “kita,
sebagai tim”, dari pada “saya, sebagai developer”.
3. Sprint Planning sekarang adalah satu acara, alih-alih terbagi menjadi dua acara tentang
“apa/bagaimana”. Dimulai dengan menentukan Sprint Goal, lalu menimbang-nimbang
apa yang dibutuhkan untuk mencapai Sprint Goal dengan kapasitas yang memungkinan
setelah ini, dan pada akhirnya membangun rencana untuk mencapai Sprint Goal pada
saat Sprint.
4. Product Backlog di-refined (baca: diperjelas atau diperhalus), alih-alih di-groomed (baca:
dikembangkan). Item-item Product Backlog yang sudah refined bersifat transparan, dan
cukup dimengerti dan terbagi-bagi dengan baik untuk jadi masukan untuk Sprint
Planning, dan dipilih untuk Sprint. Item-item Product Backlog dengan tingkat
transparansi seperti ini disebut “Siap”.
5. Semua acara memiliki batasan waktu maksimum. Sprint yang panjangnya kurang dari
dari satu bulan, biasanya secara alami tidak perlu dibatasi dengan waktu maksimum.
6. Keluaran dari Sprint Review adalah Product Backlog yang bisa diatur ulang, dengan itemitem Product Backlog bernilai tinggi memiliki kemungkinan lebih untuk dipilih di Sprint
Planning selanjutnya.
7. Sprint Planning mendefinisikan fungsionalitas sebagai Inkremen yang terencana, dan
merencanakan bagaimana Tim Pengembang akan membuat Inkremen ini. Sebuah Sprint
Goal dirancang untuk jadi rangkuman dari keluaran acara ini.
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.
Page | 19