Scrum – Framework

Ebook ini masih dalam proses editing.

Hanya untuk bahan kuliah mahasiswa
PJJ S2 Informatika tahun 2021 Universitas Amikom.
Tidak untuk dibagikan / dipublikasikan
di media apapun

Sukoco
Maret 2021

1
Scrum adalah kerangka kerja untuk mengembangkan dan mempertahankan produk yang kompleks. Ken
Schwaber dan Jeff Sutherland mengembangkan Scrum. Bersama-sama, mereka mendukung Aturan
Scrum.

Definisi Scrum
Scrum adalah kerangka kerja di mana orang dapat mengatasi masalah adaptif yang kompleks, sambil
secara produktif dan kreatif memberikan produk dengan nilai setinggi mungkin.
Scrum adalah kerangka proses yang telah digunakan untuk mengelola pengembangan produk yang
kompleks sejak awal 1990-an. Scrum bukanlah proses atau teknik untuk membangun produk;
sebaliknya, ini adalah kerangka kerja di mana Anda dapat menggunakan berbagai proses dan teknik.
Scrum menjelaskan keefektifan relatif dari pengelolaan produk dan praktik pengembangan Anda
sehingga Anda dapat meningkat.
Kerangka kerja Scrum terdiri dari Tim Scrum dan peran, acara, artefak, dan aturan terkait. Setiap
komponen dalam kerangka kerja memiliki tujuan tertentu dan penting untuk keberhasilan dan
penggunaan Scrum.
Aturan Scrum mengikat acara, peran, dan artefak, mengatur hubungan dan interaksi di antara mereka.
Aturan Scrum dijelaskan di sepanjang tutorial ini.
Catatan - Di seluruh industri, terdapat kesalahpahaman bahwa Scrum berarti tidak ada dokumentasi, tim
scrum hanya terdiri dari pengembang, dan sebagainya. Tidak sepenuhnya demikian; kami akan
memberikan klarifikasi tentang ini di bagian selanjutnya.
Kerangka Proses Scrum

Di Scrum, acara yang ditentukan digunakan untuk menciptakan keteraturan. Semua acara adalah acara
dengan batas waktu, sehingga setiap acara memiliki durasi maksimum. Peristiwa tersebut dijelaskan
lebih rinci pada bab-bab selanjutnya.

2
Sprint
Inti dari Scrum adalah Sprint, kotak waktu dua minggu atau satu bulan di mana peningkatan produk
yang berpotensi dapat dirilis dibuat. Sprint baru dimulai segera setelah Sprint sebelumnya berakhir.
Sprint terdiri dari perencanaan Sprint, rapat harian scrum, pekerjaan pengembangan, tinjauan Sprint,
dan retrospektif Sprint.
 Dalam perencanaan Sprint, pekerjaan yang akan dilakukan dalam Sprint direncanakan secara
kolaboratif oleh Tim Scrum.
 Rapat Scrum Harian adalah acara dengan batas waktu 15 menit bagi Tim Scrum untuk
menyinkronkan kegiatan dan membuat rencana untuk hari itu.
 Sprint Review diadakan di akhir Sprint untuk memeriksa Increment dan membuat perubahan
pada Product Backlog, jika diperlukan.
 Sprint Retrospective terjadi setelah Sprint Review dan sebelum Sprint Planning berikutnya.
Dalam pertemuan ini, Tim Scrum akan memeriksa dirinya sendiri dan membuat rencana
perbaikan yang akan diberlakukan selama Sprint berikutnya.

Kesimpulan
Scrum adalah kerangka proses yang mendefinisikan aturan, acara, dan peran tertentu untuk
menghadirkan keteraturan. Namun, ini dapat disesuaikan dengan organisasi mana pun, berdasarkan
kebutuhan, asalkan aturan scrum dasar tidak dilanggar.

Scrum - Roles
Tim Scrum terdiri dari tiga peran, yaitu ScrumMaster, Pemilik Produk, dan Tim.

ScrumMaster
ScrumMaster (terkadang ditulis sebagai Scrum Master, meskipun istilah resminya tidak memiliki spasi
setelah "Scrum") adalah penjaga proses scrum. Dia bertanggung jawab untuk-
 membuat proses berjalan lancar
 menghilangkan hambatan yang berdampak pada produktivitas
 mengatur dan memfasilitasi pertemuan kritis

Pemilik produk
Pemilik Produk bertanggung jawab untuk memaksimalkan nilai produk dan hasil kerja Tim. Bagaimana
hal ini dilakukan dapat sangat bervariasi antar organisasi, Tim Scrum, dan individu.
Pemilik Produk adalah satu-satunya orang yang bertanggung jawab untuk mengelola Product Backlog.
Manajemen Product Backlog meliputi-
 Mengekspresikan item Product Backlog dengan jelas.
 Memesan item Product Backlog untuk mencapai tujuan dan misi terbaik.

3
  Mengoptimalkan nilai pekerjaan yang dilakukan Tim.
 Memastikan Product Backlog terlihat, transparan, dan jelas bagi semua, dan menunjukkan apa
yang akan dikerjakan oleh Tim lebih lanjut.
 Memastikan bahwa Tim memahami item dalam Product Backlog ke tingkat yang dibutuhkan.
Pemilik Produk dapat melakukan pekerjaan di atas, atau meminta Tim untuk melakukannya. Namun,
Pemilik Produk tetap bertanggung jawab atas tugas-tugas ini.
Pemilik Produk adalah satu orang, bukan komite. Product Owner dapat mewakili keinginan panitia
dalam Product Backlog, tetapi mereka yang ingin mengubah prioritas item Product Backlog harus
memenuhi Product Owner.
Agar Pemilik Produk berhasil, seluruh organisasi harus menghormati keputusannya. Keputusan Product
Owner terlihat dalam konten dan urutan Product Backlog. Tidak seorang pun diizinkan untuk memberi
tahu Tim untuk bekerja dari serangkaian persyaratan yang berbeda, dan Tim tidak diizinkan untuk
bertindak berdasarkan apa yang dikatakan orang lain. Ini dijamin oleh ScrumMaster.

Tim
Tim ini mengatur dirinya sendiri dan berfungsi lintas. Itu berarti tim terdiri dari analis, desainer,
pengembang, penguji, dll. Yang sesuai dan relevan dengan proyek.
Beberapa orang di industri menyebut tim ini sebagai tim pengembangan. Namun, referensi semacam itu
menimbulkan kontroversi bahwa tim tersebut hanya dapat memiliki pengembang dan tidak ada peran
lain. Ini adalah pemahaman yang jelas bahwa itu hanya kesalahpahaman. Untuk mengembangkan
produk perangkat lunak, kami memerlukan semua peran dan itulah inti dari scrum - tim akan berfungsi
dalam kolaborasi. Tim lintas fungsi memiliki semua kompetensi yang dibutuhkan untuk menyelesaikan
pekerjaan tanpa bergantung pada orang lain yang bukan bagian dari tim, dan dengan demikian waktu
dan tenaga dapat dihemat. Model tim di Scrum dirancang untuk mengoptimalkan fleksibilitas,
kreativitas, dan produktivitas.
Ukuran Tim yang optimal cukup kecil untuk tetap gesit dan cukup besar untuk menyelesaikan pekerjaan
penting dalam Sprint. Ukuran tim harus berkisar antara lima sampai sembilan orang, jika
memungkinkan. Kurang dari lima anggota tim mengurangi interaksi dan menghasilkan keuntungan
produktivitas yang lebih kecil. Memiliki lebih dari sembilan anggota membutuhkan terlalu banyak
koordinasi.
Tim scrum bekerja sama secara erat, setiap hari, untuk memastikan kelancaran arus informasi dan
penyelesaian masalah yang cepat. Tim scrum memberikan produk secara berulang dan bertahap,
memaksimalkan peluang untuk umpan balik. Pengiriman tambahan dari produk yang lengkap
memastikan versi produk kerja yang berpotensi berguna selalu tersedia.

4
 Scrum - ScrumMaster
ScrumMaster adalah orang yang terlatih dan bertanggung jawab, yang memberikan layanan seperti
yang dijelaskan di bawah ini -
Layanan ScrumMaster kepada Pemilik Produk
ScrumMaster melayani Pemilik Produk dalam beberapa cara, termasuk -
 Menemukan teknik untuk manajemen Product Backlog yang efektif.
 Membantu Tim Scrum memahami kebutuhan akan item Product Backlog yang jelas dan ringkas.
 Memahami perencanaan produk dalam lingkungan empiris.
 Memastikan Product Owner mengetahui bagaimana menyusun Product Backlog untuk
memaksimalkan nilai.
 Memahami dan melatih ketangkasan.
 Memfasilitasi acara Scrum sesuai kebutuhan.
Layanan ScrumMaster untuk Tim Scrum
ScrumMaster melayani Tim Scrum dengan beberapa cara, termasuk -
 Melatih Tim Scrum dalam pengorganisasian mandiri dan lintas fungsi.
 Membantu Tim Scrum untuk membuat produk bernilai tinggi.
 Menghilangkan hambatan untuk kemajuan Tim Scrum.
 Memfasilitasi acara Scrum sesuai permintaan atau kebutuhan.
 Melatih Tim Scrum di lingkungan organisasi di mana Scrum belum sepenuhnya diadopsi dan
dipahami.
Layanan ScrumMaster untuk Organisasi
ScrumMaster melayani organisasi dengan beberapa cara, termasuk-
 Memimpin dan membimbing organisasi dalam penerapan Scrum.
 Merencanakan implementasi Scrum dalam organisasi.
 Membantu karyawan dan pemangku kepentingan memahami dan memberlakukan Scrum dan
pengembangan produk empiris.
 Membuat perubahan yang meningkatkan produktivitas Tim Scrum.
 Bekerja sama dengan ScrumMaster lain untuk meningkatkan efektivitas penerapan Scrum di
organisasi.

Kesimpulan
Scrum adalah kerangka proses yang mendefinisikan aturan, acara, dan peran tertentu untuk
menghadirkan keteraturan. Namun, ini dapat disesuaikan dengan organisasi mana pun, berdasarkan
kebutuhan, asalkan aturan scrum dasar tidak dilanggar.

5
 Scrum - Events
Kerangka Proses Scrum dapat dilihat melalui urutan kejadian dan artefak yang sesuai. Acara Scrum
adalah acara dengan batasan waktu. Artinya, dalam sebuah proyek, setiap acara scrum memiliki durasi
maksimum yang telah ditentukan sebelumnya. Acara ini memungkinkan transparansi kemajuan proyek
kepada semua yang terlibat dalam proyek. Peristiwa penting scrum adalah-
• Sprint
• Perencanaan Sprint
• Rapat Scrum Harian
• Ulasan Sprint
• Retrospektif Sprint

Sprint
Selama Sprint, Increment produk yang berfungsi dikembangkan. Biasanya berdurasi dua minggu atau
satu bulan, dan durasi ini tetap konstan untuk semua sprint dalam proyek. Kami tidak dapat memiliki
durasi yang berbeda-beda untuk sprint yang berbeda dalam sebuah proyek. Sprint baru dimulai segera
setelah Sprint sebelumnya berakhir.
Sprint Goal adalah set tujuan untuk Sprint. Ini memberikan panduan kepada Tim tentang mengapa
membangun Increment tersebut. Itu dibuat selama pertemuan Perencanaan Sprint. Ruang lingkup sprint
diklarifikasi dan dinegosiasikan ulang antara Pemilik Produk dan Tim karena lebih banyak informasi
tentang persyaratan dipelajari. Dengan demikian, setiap Sprint dikaitkan dengannya, definisi tentang
apa yang akan dibangun, desain, dan rencana fleksibel yang akan memandu pembuatannya, pekerjaan
pengembangan, dan peningkatan produk yang dihasilkan.
Sebuah Sprint harus dibatalkan jika Sprint Goal menjadi usang. Ini mungkin terjadi jika organisasi
berubah arah atau jika kondisi pasar atau teknologi berubah. Sprint hanya dapat dibatalkan oleh pemilik
produk, meskipun orang lain memiliki pengaruh yang sama.
Karena durasi Sprint yang pendek, pembatalan selama sprint jarang masuk akal. Karena pembatalan
sprint menghabiskan sumber daya, untuk mengatur ulang ke Sprint lain, hal itu sangat jarang terjadi.
Jika Sprint dibatalkan, dan bagian dari pekerjaan yang dihasilkan selama sprint berpotensi untuk dirilis,
Pemilik Produk biasanya menerimanya. Semua Item Sprint Backlog yang tidak lengkap dimasukkan
kembali ke dalam Product Backlog.

Perencanaan Sprint
Pekerjaan yang akan dilakukan dalam Sprint direncanakan dalam Rapat Perencanaan Sprint. Rapat
Perencanaan Sprint berdurasi maksimal empat jam untuk sprint dua minggu dan delapan jam untuk
Sprint satu bulan. Merupakan tanggung jawab Scrum Master untuk memastikan bahwa rapat
berlangsung dan semua peserta yang diwajibkan hadir dan memahami tujuan dari rapat yang
dijadwalkan. Scrum Master memoderasi rapat untuk memantau kelangsungan diskusi dan penutupan
tepat waktu.
Perencanaan Sprint berfokus pada dua pertanyaan berikut -
• Apa yang perlu dan dapat disampaikan dalam Sprint Increment?

6
 • Bagaimana pekerjaan yang dibutuhkan untuk pelaksanaan Sprint akan tercapai?
Masukan untuk pertemuan ini adalah -
• Product Backlog
• Penambahan produk terbaru
• Proyeksi kapasitas Tim selama Sprint
• Kinerja Tim di masa lalu
Tim Scrum membahas fungsionalitas yang dapat dikembangkan selama Sprint. Product Owner
memberikan klarifikasi pada item Product Backlog. Tim memilih item dari Product Backlog untuk Sprint,
karena mereka adalah yang terbaik untuk menilai apa yang dapat mereka capai di Sprint. Tim ini terdiri
dari analis, desainer, pengembang, dan penguji. Pengerjaan dilakukan secara kolaboratif, sehingga
meminimalkan pengerjaan ulang.
Tim Scrum kemudian membuat Sprint Goal. Sprint Goal adalah tujuan yang memberikan panduan
kepada Tim tentang mengapa mereka membangun Peningkatan Produk. Tim kemudian memutuskan
bagaimana ia akan membangun fungsionalitas yang dipilih menjadi Increment produk yang berfungsi
selama Sprint. Item Product Backlog yang dipilih untuk Sprint ini ditambah rencana pengirimannya
disebut Sprint Backlog.
Pekerjaan selama sprint diperkirakan selama perencanaan sprint dan mungkin memiliki ukuran dan /
atau usaha yang bervariasi. Di akhir rapat Perencanaan Sprint, pekerjaan dibagi menjadi tugas-tugas
yang berdurasi satu hari atau kurang. Ini untuk memungkinkan kemudahan alokasi pekerjaan, dan
melacak penyelesaian. Jika Tim menyadari bahwa pekerjaannya terlalu banyak atau terlalu sedikit, Tim
dapat menegosiasikan kembali item Product Backlog yang dipilih dengan Pemilik Produk.
Tim juga dapat mengundang orang lain (bukan bagian dari Tim Scrum) untuk menghadiri pertemuan
Perencanaan Sprint untuk mendapatkan nasihat teknis atau domain atau bantuan dalam
memperkirakan.

Rapat Scrum Harian

Rapat Scrum Harian adalah rapat 15 menit untuk Tim, dilakukan setiap hari untuk memahami pekerjaan
dengan cepat sejak Rapat Scrum Harian terakhir dan membuat rencana untuk 24 jam ke depan. Rapat
ini juga disebut Rapat Stand up Harian.
Rapat Scrum Harian diadakan di waktu dan tempat yang sama setiap hari untuk mengurangi kerumitan.
Selama rapat, setiap anggota Tim menjelaskan -
• Apa yang dia lakukan kemarin yang membantu Tim mencapai Sprint Goal?
• Apa yang akan dia lakukan hari ini untuk membantu Tim mencapai Sprint Goal?
• Apakah dia melihat halangan yang menghalangi dia atau Tim untuk memenuhi Sprint Goal?
Daily Scrum disalahartikan sebagai event pelacakan status, padahal sebenarnya itu adalah event
perencanaan.
Masukan untuk pertemuan tersebut harus bagaimana kinerja tim untuk mencapai Tujuan Sprint, dan
keluarannya harus berupa rencana baru atau revisi yang mengoptimalkan upaya tim dalam memenuhi
Tujuan Sprint.

7
Meskipun Scrum Master mengkoordinasikan Rapat Scrum Harian dan memastikan bahwa tujuan rapat
terpenuhi, Rapat adalah tanggung jawab Tim.
Jika perlu, Tim dapat bertemu segera setelah Rapat Scrum Harian, untuk diskusi mendetail, atau untuk
merencanakan ulang sisa pekerjaan Sprint.
Berikut adalah manfaat Rapat Scrum Harian -
• Meningkatkan komunikasi dalam Tim.
• Identifikasi hambatan, jika ada, untuk memfasilitasi penghapusan awal yang sama, untuk
meminimalkan dampak pada Sprint.
• Soroti dan promosikan pengambilan keputusan yang cepat.
• Meningkatkan tingkat pengetahuan Tim.

Ulasan Sprint (Sprint Review)

Ulasan Sprint diadakan di akhir setiap Sprint. Selama Sprint Review, presentasi kenaikan yang akan dirilis
ditinjau. Dalam pertemuan ini, Tim Scrum dan para pemangku kepentingan berkolaborasi untuk
memahami apa yang telah dilakukan di Sprint. Berdasarkan itu, dan setiap perubahan pada Product
Backlog selama Sprint, peserta sampai pada langkah selanjutnya yang diperlukan untuk mengoptimalkan
nilai. Jadi, tujuan dari Sprint Review adalah untuk mendapatkan umpan balik dan kemajuan secara
bersama-sama.
Sprint Review biasanya diadakan selama dua jam untuk sprint dua minggu dan selama empat jam untuk
sprint satu bulan.
Scrum Master memastikan bahwa -
• Pertemuan berlangsung.
• Peserta memahami tujuannya.
• Rapat difokuskan pada agenda yang dibutuhkan dan diselesaikan dalam durasi yang disyaratkan.
Ulasan Sprint mencakup aspek-aspek berikut -
• Peserta termasuk Tim Scrum dan pemangku kepentingan utama, sebagaimana diundang oleh
Pemilik Produk.
• Pemilik Produk menjelaskan item Product Backlog apa yang telah diselesaikan selama sprint dan
apa yang belum diselesaikan.
• Tim membahas apa yang berjalan dengan baik selama Sprint, masalah apa yang ditemuinya, dan
bagaimana masalah tersebut diselesaikan.
• Tim mendemonstrasikan pekerjaan yang telah diselesaikannya dan menjawab pertanyaan, jika
ada, tentang Penambahan.
• Seluruh kelompok kemudian berdiskusi tentang apa yang harus dilakukan selanjutnya. Dengan
demikian, Ulasan Sprint memberikan masukan yang berharga untuk Perencanaan Sprint dari
Sprint berikutnya.
• Tim Scrum kemudian meninjau jadwal, anggaran, kapabilitas potensial, dan pasar untuk
antisipasi rilis kenaikan produk berikutnya.

8
 • Hasil dari Review Sprint adalah Product Backlog yang diperbarui, yang mendefinisikan item
Product Backlog yang mungkin untuk Sprint berikutnya.

Sprint Retrospective
Sprint Retrospective terjadi setelah Sprint Review dan sebelum Sprint Planning berikutnya. Ini biasanya
pertemuan satu jam untuk sprint durasi dua minggu dan pertemuan tiga jam untuk sprint durasi satu
bulan.
Tujuan dari Sprint Retrospective adalah untuk -
• Gabungkan pembelajaran dari Sprint terakhir, yang berkaitan dengan orang, hubungan, proses,
dan alat.
• Mengidentifikasi item-item utama yang berjalan dengan baik dan potensi peningkatannya.
• Pembuatan rencana implementasi perbaikan untuk meningkatkan kualitas produk.
Sprint Retrospective adalah kesempatan bagi Tim Scrum untuk melakukan introspeksi dan peningkatan
dalam kerangka proses Scrum untuk membuat hasil Sprint berikutnya lebih efektif.
Referensi
Panduan Scrum © 1991-2013 Ken Schwaber dan Jeff Sutherland, Semua Hak Dilindungi Undang-Undang.

9
 Scrum - Artefak
Artefak Scrum memberikan informasi kunci yang perlu diketahui oleh Tim Scrum dan pemangku
kepentingan untuk memahami produk yang sedang dikembangkan, aktivitas yang dilakukan, dan
aktivitas yang direncanakan dalam proyek. Artefak berikut ini didefinisikan dalam Scrum Process
Framework -
• Product Backlog
• Sprint Backlog
• Grafik Burn-Down
• Penambahan
Ini adalah artefak minimum yang diperlukan dalam proyek scrum dan artefak proyek tidak dibatasi oleh
ini.

Product Backlog
Product Backlog adalah daftar fitur yang diperlukan sebagai bagian dari produk akhir dan merupakan
satu-satunya sumber persyaratan untuk setiap perubahan yang akan dilakukan pada produk.
Product Backlog mencantumkan semua fitur, fungsi, persyaratan, peningkatan, dan perbaikan yang
merupakan perubahan yang harus dilakukan pada produk di rilis mendatang. Item Product Backlog
memiliki atribut deskripsi, urutan, estimasi, dan nilai. Item ini biasanya disebut sebagai Kisah Pengguna.
Product Owner bertanggung jawab atas Product Backlog, termasuk konten, ketersediaan, dan
pemesanannya.
Product Backlog adalah artefak yang terus berkembang. Versi paling awal mungkin hanya berisi
persyaratan yang awalnya diketahui dan paling dipahami. Product Backlog dikembangkan sebagai
produk, dan lingkungan di mana ia akan digunakan, berkembang. Product Backlog secara konstan
berubah untuk memasukkan apa yang dibutuhkan untuk membuatnya efektif. Selama suatu produk ada,
Product Backlog-nya juga ada.
Saat produk yang sedang dibangun digunakan dan memperoleh nilai, Product Backlog menjadi daftar
yang lebih besar dan lebih lengkap. Perubahan persyaratan bisnis, kondisi pasar, atau teknologi,
menyebabkan perubahan pada Product Backlog, menjadikannya artefak yang hidup.
Penyempurnaan Product Backlog berarti menambahkan detail, estimasi, dan urutan prioritas pada item
Product Backlog. Ini adalah proses berkelanjutan yang dilakukan oleh Pemilik Produk dan Tim. Tim
Scrum memutuskan bagaimana dan kapan perbaikan harus dilakukan.
Item Product Backlog dapat diperbarui kapan saja oleh Pemilik Produk atau atas kebijakan Pemilik
Produk.
Item Product Backlog dengan urutan lebih tinggi biasanya lebih jelas dan lebih detail daripada item
dengan urutan lebih rendah. Perkiraan yang lebih tepat dibuat berdasarkan kejelasan yang lebih baik
dan detail yang ditingkatkan. Semakin rendah urutannya, semakin rendah detailnya.
Item Product Backlog yang mungkin menjadi persyaratan kandidat untuk Sprint mendatang akan
diperbaiki sehingga item ini dapat dikembangkan selama Sprint. Item Product Backlog yang dapat
dikembangkan oleh Tim dalam satu Sprint dianggap siap untuk dipilih dalam rapat perencanaan Sprint.

10
Sprint Backlog
Sprint Backlog adalah sekumpulan item Product Backlog yang dipilih untuk Sprint, ditambah rencana
untuk mengirimkan Increment produk dan merealisasikan Sprint Goal.
Sprint Backlog adalah ramalan oleh Tim tentang fungsionalitas apa yang akan tersedia di Increment
berikutnya dan pekerjaan yang diperlukan untuk memberikan fungsionalitas tersebut sebagai Increment
produk yang berfungsi.
Sprint Backlog adalah rencana dengan detail yang cukup yang dapat dipahami tetapi Tim harus
melacaknya di Daily Scrum. Tim memodifikasi Sprint Backlog selama Sprint, dan Sprint Backlog muncul
selama Sprint. Kemunculan ini terjadi saat Tim mengerjakan rencana dan belajar lebih banyak tentang
pekerjaan yang diperlukan untuk mencapai Sprint Goal.
Karena pekerjaan baru diperlukan, Tim menambahkannya ke Sprint Backlog. Saat pekerjaan dilakukan
atau diselesaikan, perkiraan pekerjaan yang tersisa diperbarui. Ketika elemen rencana dianggap tidak
perlu, mereka dihapus. Hanya Tim yang dapat mengubah Sprint Backlognya selama Sprint. Sprint
Backlog adalah gambaran real-time yang sangat terlihat dari pekerjaan yang direncanakan Tim untuk
diselesaikan selama Sprint, dan itu hanya milik Tim.

Kenaikan, Increment
Increment adalah jumlah dari semua item Product Backlog yang diselesaikan selama Sprint digabungkan
dengan peningkatan dari semua Sprint sebelumnya. Di akhir Sprint, Increment baru harus merupakan
produk yang berfungsi, yang berarti harus dalam kondisi yang bisa digunakan. Itu harus dalam kondisi
kerja terlepas dari apakah Pemilik Produk memutuskan untuk benar-benar merilisnya.
Tim Scrum perlu memiliki konsensus tentang apa yang dianggap sebagai Increment. Ini sangat bervariasi
untuk setiap Tim Scrum, tetapi, anggota tim harus memiliki pemahaman yang sama tentang apa artinya
pekerjaan yang akan diselesaikan. Ini digunakan untuk menilai saat pekerjaan selesai pada Penambahan
produk.
Pemahaman yang sama memandu Tim untuk mengetahui berapa banyak item Product Backlog yang
dapat dipilihnya selama Perencanaan Sprint. Tujuan dari setiap Sprint adalah untuk memberikan
Penambahan fungsionalitas yang berpotensi dapat dirilis.
Tim memberikan peningkatan fungsionalitas produk setiap Sprint. Kenaikan ini dapat digunakan, jadi
Pemilik Produk dapat memilih untuk segera merilisnya. Jika pemahaman tentang increment adalah
bagian dari konvensi, standar, atau pedoman organisasi pengembangan, semua Scrum Team minimal
harus mengikutinya. Jika ini bukan merupakan konvensi dari organisasi pengembang, Tim Scrum harus
mendefinisikan definisi Increment yang sesuai untuk produk tersebut.
Setiap Penambahan merupakan tambahan untuk semua Penambahan sebelumnya dan diuji secara
menyeluruh, memastikan bahwa semua Penambahan berfungsi bersama.
Seiring bertambahnya usia Tim Scrum, definisi Inkremen mereka diharapkan meluas hingga mencakup
kriteria yang lebih ketat untuk kualitas yang lebih tinggi. Setiap produk harus memiliki definisi Increment
yang merupakan standar untuk setiap pekerjaan yang dilakukan padanya.Sprint Burn-Down Chart
Setiap saat dalam Sprint, total pekerjaan yang tersisa di Sprint Backlog dapat dijumlahkan. Tim melacak
total pekerjaan yang tersisa untuk setiap Pertemuan Harian untuk memproyeksikan kemungkinan
mencapai Sprint Goal. Dengan melacak pekerjaan yang tersisa di sepanjang Sprint, Tim dapat mengatur
kemajuannya.

11
Sprint Burn-Down Chart adalah latihan untuk tren pekerjaan yang dikeluarkan oleh Tim Scrum. Ini telah
terbukti menjadi teknik yang berguna dalam memantau kemajuan Sprint menuju Sprint Goal.
Pemilik Produk melacak total pekerjaan yang tersisa setidaknya di setiap Sprint Review. Pemilik Produk
membandingkan jumlah ini dengan pekerjaan yang tersisa di Tinjauan Sprint sebelumnya untuk menilai
kemajuan dalam menyelesaikan pekerjaan yang diproyeksikan pada waktu yang diinginkan untuk
mencapai tujuan. Informasi ini dibagikan dengan semua pemangku kepentingan.
Kesimpulan
Peran, acara, artefak, dan aturan Scrum tidak bisa dihindari. Jika hanya beberapa bagian dari Scrum yang
diimplementasikan, hasilnya bukanlah Scrum. Scrum perlu diimplementasikan secara keseluruhan dan
berfungsi dengan baik jika sejalan dengan teknik, metodologi, dan praktik lain.
ReferensiScrum Guide © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved.

12
 Scrum - Kisah Pengguna/ User Stories
Seperti yang Anda ketahui, Kisah Pengguna biasanya digunakan untuk mendeskripsikan fitur produk dan
akan menjadi bagian dari Artefak Scrum - Product Backlog dan Sprint Backlog.

Kisah Pengguna
Dalam pengembangan perangkat lunak, fitur produk memainkan peran penting. Ini adalah fitur yang
pada akhirnya suka digunakan pengguna dalam produk akhir. Mereka dikenal sebagai Persyaratan dalam
terminologi umum. Keberhasilan proyek pengembangan perangkat lunak terletak pada pemahaman
kebutuhan pengguna secara akurat dan tepat, dan kemudian menerapkannya dalam produk akhir.
Dengan demikian, persyaratan atau fitur produk perlu diketahui secara menyeluruh oleh tim proyek
pengembangan.
Pada tahun 1999, Kent Beck muncul dengan istilah Kisah Pengguna untuk fitur produk. Dia menjelaskan
bahwa Kisah Pengguna dinarasikan dari perspektif pengguna mengenai apa yang dia ingin miliki
daripada apa yang dapat dilakukan sistem untuknya. Dengan demikian, tampilan berubah dari produk ke
pengguna sepenuhnya dan Kisah Pengguna menjadi standar de facto untuk Persyaratan di semua
kerangka kerja Agile.
Dalam proyek Scrum, Product Backlog adalah daftar cerita pengguna. Kisah Pengguna ini diprioritaskan
dan dimasukkan ke dalam Sprint Backlog dalam Rapat Perencanaan Sprint.
Estimasi juga didasarkan pada cerita pengguna dan ukuran produk diperkirakan di Poin Cerita Pengguna.

Struktur Kisah Pengguna

Struktur Kisah Pengguna adalah sebagai berikut -

As a <Type of User>,

I want <To Perform Some Task>,

So that <I can achieve some goal/benefit/value>.

Mari kita lihat bagaimana kisah pengguna dibingkai untuk skenario Nasabah Bank menarik uang tunai
dari ATM.

User Story: Customer’s Cash Withdrawal (Penarikan Tunai Pelanggan)

As a Customer,

I want to withdraw cash from an ATM,

So that I don't have to wait in line at the Bank

Kriteria Penerimaan/ Acceptance Kisah Pengguna

13
Setiap Kisah Pengguna juga memiliki Kriteria Penerimaan yang ditentukan, sehingga kebenaran
implementasi cerita pengguna dipastikan dengan lulus Uji Terima yang didasarkan pada Kriteria
Penerimaan.
Berikut adalah contoh kriteria penerimaan untuk contoh Penarikan Tunai Pelanggan dari Kisah
Pengguna.
Acceptance Criterion 1:
Given bahwa akun tersebut layak kredit
• Dan kartu itu valid
• Dan dispenser berisi uang tunai,
When pelanggan meminta uang tunai
Then pastikan akun tersebut didebit
• Dan memastikan uang tunai dibagikan
• Dan pastikan kartunya dikembalikan.

Acceptance Criterion 2:

Given bahwa akun tersebut kelebihan penarikan

• Dan kartu itu valid

When pelanggan meminta uang tunai

Then pastikan pesan penolakan ditampilkan

• Dan pastikan uang tunai tidak dibagikan

• Dan pastikan kartunya dikembalikan.

Menulis User Stories

Pemilik Produk bertanggung jawab atas Product Backlog dan karenanya juga untuk Kisah Pengguna.
Namun, ini tidak berarti bahwa hanya pemilik produk yang menulis cerita pengguna. Siapa pun di Tim
Scrum dapat menulis cerita pengguna, dan aktivitasnya dapat disebarkan ke seluruh proyek saat
persyaratan diperbaiki dan fungsionalitas baru ditambahkan.
Persyaratan Non-Fungsional di Kisah Pengguna
Dimungkinkan untuk memasukkan persyaratan non-fungsional juga dalam cerita pengguna. Dalam
contoh ATM yang diberikan, ATM yang akan tersedia untuk pengguna 24X7, 365 hari adalah persyaratan
non-fungsional, yang dapat dijelaskan dengan kasus penggunaan.
Mengelola Kisah Pengguna
Kisah Pengguna dikelola di Product Backlog. Kisah Pengguna diurutkan menurut prioritas. Kisah
pengguna yang paling diprioritaskan disaring ke tingkat yang terperinci, sedangkan kisah pengguna

14
dengan prioritas paling rendah disimpan pada tingkat detail yang lebih rendah. Untuk setiap sprint,
cerita pengguna yang paling diprioritaskan dan karenanya lebih terperinci dimasukkan ke dalam sprint
backlog. Jika cerita pengguna akan ditambahkan ke backlog produk, prioritasnya ditentukan terlebih
dahulu, dan ditempatkan sesuai dengan tempatnya sesuai prioritas. Kisah pengguna dapat diprioritaskan
ulang kapan saja. Dimungkinkan juga untuk menghapus salah satu cerita pengguna jika diperlukan.
Manfaat dengan Kisah Pengguna
• Manfaat utama Kisah Pengguna terletak pada definisi yang berpusat pada pengguna itu sendiri.
Ini karena, pada akhirnya, pengguna yang akan menggunakan produk dalam skenario pengguna
yang relevan. Ini menghubungkan pengguna akhir ke anggota tim.
• Sintaks Kisah Pengguna itu sendiri memastikan untuk menangkap tujuan atau manfaat atau nilai
yang ingin dicapai pengguna.
• Karena kriteria penerimaan merupakan bagian dari kisah pengguna itu sendiri, ini akan menjadi
keuntungan tambahan bagi Tim Scrum.
• Dimungkinkan untuk membuat perubahan pada cerita pengguna selama pelaksanaan proyek.
Jika cakupan cerita pengguna menjadi besar, itu perlu dibagi menjadi cerita pengguna yang lebih
kecil. Kondisi dalam kriteria penerimaan juga bisa diubah.
• Karena peningkatan produk yang berfungsi dikirimkan ke pengguna di akhir setiap sprint, tim
scrum bisa mendapatkan umpan balik dari pengguna dalam rapat tinjauan sprint. Ini
memungkinkan penggabungan umpan balik ke dalam produk secara terus menerus.
Kesimpulan
Kisah Pengguna Scrum membawa pengguna lebih dekat ke tim Scrum dan mencegah kejutan di menit-
menit terakhir.

15
 Scrum - Burn-Down Charts
Pelacakan sprint biasanya dilakukan dengan menggunakan Burn-Down Chart. Bagan Burn-Down
menunjukkan upaya yang tersisa dalam jumlah jam sehari-hari. Misalnya, mari kita pertimbangkan
sprint 2 minggu -
• Durasi Sprint: 2 Minggu
• Jumlah Hari per Minggu: 5
• Jumlah Jam. per Hari: 6
• Jumlah Sumber Daya: 6

Karenanya, total usaha yang tersisa di awal sprint adalah 2 * 5 * 6 * 6 = 360 jam.
Oleh karena itu, dalam skenario yang ideal, 36 jam kerja berkurang di sisa pekerjaan dan grafik burn-
down terlihat sebagai berikut -

Jika pekerjaan sprint dilakukan sesuai rencana setiap hari, kemajuan scrum hampir sejajar dengan bar
yang ideal.
Jika pekerjaan sprint tertunda dan komitmen waktu tidak terpenuhi, grafik burn-down terlihat
sebagaiberikut -

Namun, karena grafik burn-down dibuat setiap hari, dan slippage diketahui lebih awal, tindakan korektif
dapat diambil untuk memenuhi garis waktu sprint. Misalkan, tim melakukan peregangan untuk

16
memenuhi garis waktu, grafik burn-down terlihat sebagai berikut -

Dengan demikian, pada titik waktu mana pun dalam Sprint, total pekerjaan yang tersisa dalam Sprint
dapat divisualisasikan dan kemungkinan pertemuan sprint timeline dapat ditingkatkan.
Kesimpulan
Grafik burn-down membantu tim Scrum untuk melacak kemajuan mereka dan apa yang perlu dilakukan
untuk memenuhi tujuan sprint.

17
 Scrum – Estimation/ Perkiraan
Dalam Proyek Scrum, Estimasi dilakukan oleh seluruh tim selama Rapat Perencanaan Sprint. Tujuan
Estimasi adalah untuk mempertimbangkan Kisah Pengguna Sprint berdasarkan Prioritas dan oleh
Kemampuan tim untuk menyampaikan selama Kotak Waktu Sprint.
Pemilik Produk memastikan bahwa Kisah Pengguna yang diprioritaskan jelas, dapat ditaksir, dan dibawa
ke awal Product Backlog.
Karena Tim Scrum secara total bertanggung jawab atas pengiriman selisih produk, perhatian akan
diberikan untuk memilih Kisah Pengguna untuk Sprint berdasarkan ukuran Kenaikan Produk dan upaya
yang diperlukan untuk hal yang sama.
Ukuran Penambahan Produk diperkirakan dalam Poin Cerita Pengguna. Setelah ukuran ditentukan,
upaya diestimasi dengan menggunakan data masa lalu, yaitu, upaya per Poin Cerita Pengguna yang
disebut Produktivitas.
Teknik Estimasi Scrum
Estimasi Scrum dari Kisah Pengguna adalah dalam hal tingkat kesulitan untuk masing-masing Kisah
Pengguna. Untuk menilai tingkat kesulitan, skala tertentu digunakan.
Ada beberapa jenis skala yang digunakan dalam Scrum Estimation. Berikut adalah beberapa contohnya -
• Ukuran Numerik (1 hingga 10)
• Ukuran Kaos (XS, S, M, L, XL XXL, XXXL)
• Deret Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, dll.)
• Trah Anjing (Chihuahua, ………, Great Dane)
Teknik estimasi biasanya dipilih sedemikian rupa sehingga seluruh tim scrum mengenal dan nyaman
dengan nilai-nilai skala. Teknik yang paling umum digunakan dan paling populer adalah Perencanaan
Poker yang didasarkan pada deret Fibonacci.
Teknik Perencanaan Poker
Dalam Teknik Estimasi Poker Perencanaan, perkiraan untuk Kisah Pengguna diperoleh dengan bermain
poker perencanaan. Seluruh Tim Scrum terlibat dan ini menghasilkan perkiraan yang cepat namun dapat
diandalkan.
Perencanaan Poker dimainkan dengan setumpuk kartu. Saat deret Fibonacci digunakan, kartu memiliki
angka - 1, 2, 3, 5, 8, 13, 21, 34, dll. Angka-angka ini mewakili Poin Cerita. Setiap penaksir memiliki
setumpuk kartu. Angka pada kartu harus cukup besar agar dapat dilihat oleh semua anggota tim, ketika
salah satu anggota tim memegang sebuah kartu.
Salah satu anggota tim dipilih sebagai Moderator. Moderator membacakan deskripsi Kisah Pengguna
yang sedang dibuat perkiraannya. Jika penaksir memiliki pertanyaan, Pemilik Produk menjawabnya.
Setiap penaksir secara pribadi memilih kartu yang mewakili perkiraannya. Kartu tidak akan ditampilkan
sampai semua penaksir telah membuat pilihan. Pada saat itu, semua kartu secara bersamaan dibalik dan
diangkat sehingga semua anggota tim dapat melihat perkiraan masing-masing.

18
Pada babak pertama, kemungkinan besar perkiraannya berbeda-beda. Estimator tinggi dan rendah
menjelaskan alasan estimasi mereka. Harus diperhatikan bahwa semua diskusi dimaksudkan untuk
memahami saja dan tidak ada yang dianggap pribadi. Moderator harus memastikan hal yang sama.
Tim dapat mendiskusikan cerita dan perkiraan mereka selama beberapa menit lagi.
Moderator dapat membuat catatan tentang diskusi yang akan berguna saat cerita spesifik
dikembangkan. Setelah pembahasan, masing-masing estimator melakukan estimasi ulang dengan
memilih kembali sebuah kartu. Kartu sekali lagi dirahasiakan sampai semua orang memperkirakan, pada
titik mana mereka akan diserahkan pada waktu yang sama.
Ulangi proses tersebut hingga perkiraan menyatu menjadi satu perkiraan yang dapat digunakan untuk
cerita. Jumlah putaran estimasi dapat bervariasi dari satu cerita pengguna ke cerita pengguna lainnya.
Manfaat Perencanaan Estimasi Poker
Perencanaan poker menggabungkan tiga metode estimasi -
Opini Pakar: Dalam pendekatan Estimasi Berbasis Opini Pakar, seorang pakar ditanyai berapa lama
sesuatu akan berlangsung atau seberapa besar itu akan terjadi. Pakar memberikan perkiraan
berdasarkan pengalaman atau intuisi atau firasatnya.
Estimasi Opini Ahli biasanya tidak memakan banyak waktu dan lebih akurat dibandingkan dengan
beberapa metode analisis.
Analogy: Analogy Estimation menggunakan perbandingan User Stories. Kisah Pengguna di bawah
Estimasi dibandingkan dengan Kisah Pengguna serupa yang diterapkan sebelumnya. Ini menghasilkan
hasil yang akurat karena estimasi didasarkan pada data yang sudah terbukti.
Disagregasi: Estimasi Disagregasi dilakukan dengan membagi Kisah Pengguna menjadi Kisah Pengguna
yang lebih kecil dan lebih mudah diperkirakan. Cerita pengguna yang akan dimasukkan dalam Sprint
biasanya berkisar antara dua hingga lima hari untuk dikembangkan. Karenanya, Kisah Pengguna yang
mungkin membutuhkan durasi lebih lama perlu dipecah menjadi Kasus Penggunaan yang lebih kecil.
Pendekatan ini juga memastikan bahwa akan ada banyak cerita yang bisa dibandingkan.
Kesimpulan
Perencanaan Poker adalah pendekatan yang menyenangkan, namun produktif untuk memperkirakan.
Karena sesi terbuka untuk diskusi sebelum perkiraan akhir tiba, akan mudah bagi tim untuk mencapai
konsensus dan juga memiliki pandangan luas tentang implementasi Kisah Pengguna yang ada.

19
 Scrum - Tools
Alat Scrum memfasilitasi perencanaan dan pelacakan untuk proyek-proyek Scrum. Mereka menyediakan
satu tempat untuk mengelola product backlog, sprint backlog, merencanakan dan melacak Sprint,
menampilkan grafik Burndown, melakukan Rapat Scrum harian, dan melakukan Retrospektif Scrum.
Ada banyak jenis Alat Scrum yang tersedia. Beberapa gratis (open source), beberapa berbayar, dan
untuk beberapa, Anda mendapatkan versi suling dari alat tersebut. Namun, untuk mendapatkan semua
fitur dan skalabilitas, Anda perlu membeli versi lengkap.

Alat Scrum yang Tersedia

Berikut ini adalah daftar dari beberapa Alat Scrum yang tersedia di pasar pada hari itu. Alat Open Source
ditandai dengan Asterisk.

20
Kesimpulan
Agile secara umum, Scrum secara spesifik tidak berarti tidak ada dokumentasi yang bekerja. Artefak
Scrum ditentukan, Perencanaan dan Penelusuran Scrum dibuat dengan baik.
Scrum Tools memfasilitasi dalam menangkap dan melacak informasi mengenai Proyek Scrum. Pilihan
alat bergantung pada fitur yang dibutuhkan oleh organisasi, selain kebutuhan alat lainnya.

Scrum – Manfaat
Scrum mendukung kolaborasi berkelanjutan antara pelanggan, anggota tim, dan pemangku kepentingan
terkait. Pendekatannya yang dibatasi waktu dan umpan balik berkelanjutan dari pemilik produk
memastikan produk yang berfungsi dengan fitur-fitur penting setiap saat. Selain itu, Scrum memberikan
manfaat yang berbeda untuk peran yang berbeda dalam proyek.
Manfaat bagi Pelanggan
Sprint berdurasi lebih pendek dan cerita pengguna yang diprioritaskan diambil di setiap perencanaan
sprint. Ini memastikan bahwa di setiap pengiriman sprint, fitur-fitur yang diminta oleh pelanggan segera
disertakan. Selanjutnya, jika pelanggan mengajukan permintaan perubahan, itu akan diserap dalam
sprint saat ini, atau dimasukkan ke dalam sprint berikutnya. Karenanya, tim pengembangan dengan
cepat menanggapi kebutuhan pelanggan dengan sangat cepat.
Manfaat bagi Organisasi
Organisasi dapat fokus pada upaya yang diperlukan untuk pengembangan cerita pengguna yang
diprioritaskan dan dengan demikian mengurangi biaya overhead dan pengerjaan ulang. Karena manfaat
khusus scrum bagi pelanggan, peningkatan efisiensi tim pengembangan, kepuasan pelanggan dan
karenanya retensi pelanggan dan referensi pelanggan akan dimungkinkan. Ini meningkatkan potensi
pasar organisasi.
Manfaat bagi Manajer Produk
Manajer Produk berperan sebagai Pemilik Produk dalam proyek tersebut. Tanggung jawab pemilik
produk adalah memastikan kepuasan pelanggan. Karena Scrum memfasilitasi respons cepat,
memprioritaskan pekerjaan, menyerap perubahan, manajer produk dapat dengan mudah memastikan
bahwa pekerjaan tersebut selaras dengan kebutuhan pelanggan, yang pada gilirannya memastikan
kepuasan pelanggan.
Manfaat bagi Manajer Proyek
Manajer Proyek berperan sebagai Scrum Master dalam proyek tersebut. Sifat kolaboratif Scrum
memfasilitasi perencanaan dan pelacakan yang mudah dan konkret. Penggunaan Grafik Pembakaran
untuk memahami pekerjaan yang tersisa, dan pertemuan Scrum Harian memberikan kesadaran Manajer
Proyek tentang keadaan proyek setiap saat. Kesadaran ini penting untuk memantau proyek, dan untuk
menangkap dan menangani masalah dengan cepat.
Manfaat bagi Tim Pengembang
Karena sifat sprint yang dibatasi waktu dan pengiriman peningkatan produk yang bekerja di akhir setiap
sprint, tim pengembangan menjadi antusias untuk melihat bahwa pekerjaan mereka segera digunakan.

21
Kolaborasi tim yang dibangun membuat tim menikmati pekerjaan yang mereka lakukan. Karena cerita
pengguna untuk setiap sprint didasarkan pada prioritas pelanggan, tim juga memahami bahwa
pekerjaan mereka dihargai.

Scrum - Certifications
Sertifikasi Scrum ditawarkan oleh Scrum Alliance. Sertifikasi berikut ditawarkan -
• Certified ScrumMaster (CSM)
• Certified Scrum Product Owner (CSPO)
• Certified Scrum Practitioner (CSP)
• Certified Scrum Coach (CSC)
• Certified Scrum Trainer (CST)

ScrumMaster Bersertifikat (CSM)

Scrum Master Tersertifikasi adalah sertifikasi dasar untuk menjadi anggota Scrum Alliance, memainkan
Peran Scrum Master, dan memenuhi syarat untuk sertifikasi lainnya. Sertifikasi ini membutuhkan
kehadiran kursus CSM. Setelah itu, kandidat mendapatkan email yang berisi rincian keanggotaan Scrum
dan ujian online CSM. Setelah mengikuti ujian, calon diberikan sertifikasi Certified ScrumMaster (CSM).
Pemilik Produk Scrum Bersertifikat (CSPO)
Pemilik Produk Scrum Bersertifikat adalah sertifikasi dasar untuk menjadi anggota Scrum Alliance,
memainkan peran Pemilik Produk, dan memenuhi syarat untuk sertifikasi lainnya.
Praktisi Scrum Bersertifikat (CSP)
Certified Scrum Practitioner adalah sertifikasi untuk ScrumMasters berpengalaman dan Pemilik Produk.
Kandidat haruslah seorang ScrumMaster atau Pemilik Produk setidaknya selama satu tahun. Kandidat
harus mengajukan lamaran yang berisi deskripsi mendetail tentang apa yang telah dia lakukan dalam
peran yang ditentukan.
Calon dapat memperoleh sertifikasi CSP segera setelah sertifikasi CSM atau sertifikasi CSPO, asalkan
kandidat secara aktif mempraktikkan peran ScrumMaster, atau peran Pemilik Produk selama durasi yang
diperlukan.
Pelatih Scrum Bersertifikat (CSC)
Certified Scrum Coach adalah sertifikasi bagi mereka yang fokus pada pembinaan. Sertifikasi tersebut
mensyaratkan bahwa kandidat tersebut telah melatih Tim Scrum melalui adopsi dan penguasaan Scrum
setidaknya selama 1500 jam dalam 5 tahun terakhir.
Pelatih Scrum Bersertifikat (CST)
Certified Scrum Trainer adalah sertifikasi bagi mereka yang ingin mengajar kelas CSM atau CSPO.
Pelamar harus memiliki CSM atau CSPO, dan harus menjadi CSP setidaknya satu tahun sebelum
mendaftar

22
 Scrum - FAQs
Berikut adalah beberapa FAQ tentang Scrum -
Pertanyaan: Apa perbedaan antara Scrum dan Agile Development?
Jawaban: Agile Development adalah metodologi perangkat lunak, sedangkan Scrum adalah salah satu
kerangka kerja proses yang mengikuti Agile.
Pertanyaan: Apakah Sprint dan Iterasi sama?
Jawaban: Baik Sprints of Scrum dan Iteration of Iterative Incremental model memberikan peningkatan
produk yang berfungsi. Namun, ini berbeda dalam hal:
• Siklus Sprint dan Iterasi berbeda.
• Sprint memiliki batasan waktu, sedangkan Iterasi tidak.
• Durasi Sprint jauh lebih sedikit dibandingkan dengan durasi Iterasi.
Pertanyaan: Apakah Scrum Master adalah jabatan atau peran yang diisi oleh seseorang dengan jabatan
yang sudah ada?
Jawaban: Scrum Master adalah peran yang diisi oleh seseorang dengan jabatan. Praktik normal adalah
bahwa orang yang berperan sebagai manajer proyek memainkan peran ScrumMaster juga.
Pertanyaan: Dapatkah Pemilik Produk dan peran ScrumMaster dimainkan oleh orang yang sama?
Jawaban: Tidak, karena kepemilikannya berbeda. Pemilik Produk menangani Product Backlog, Prioritas
Cerita Pengguna, dan Validasi peningkatan produk yang berfungsi dengan cerita pengguna yang
dialokasikan ke Sprint.
Pertanyaan: Apakah Proyek Scrum tidak membutuhkan Dokumentasi?
Jawaban: Tidak. Proyek Scrum, seperti Proyek lainnya memerlukan dokumentasi seperti cerita
pengguna, desain, kasus uji, dll.
Kesimpulan
Agile dan Scrum tidak sama. Scrum adalah salah satu kerangka proses yang mengadaptasi Agile. Scrum
disarankan untuk tim dengan anggota tim yang berpengalaman karena Kerangka ini membutuhkan
kolaborasi dan organisasi mandiri yang hebat juga. Jika aturan Scrum tidak diikuti dengan ketat, sebuah
proyek dapat menyebabkan kegagalan. Oleh karena itu, diperlukan pemahaman yang benar tentang
konsep Scrum di antara seluruh tim. Karena Sprint berdurasi pendek dan dibatasi waktu, tidak ada
waktu untuk mempelajari Scrum secara spesifik dalam pekerjaannya, bahkan ketika Scrum Master terus
memantau proyek tersebut.

23