Identifikasi dan bandingkan peran penting dalam tim Scrum dan apa yang membuatnya efektif

Tujuan Panduan Scrum Scrum adalah kerangka kerja untuk mengembangkan, memberikan, dan mempertahankan produk yang kompleks. Panduan ini berisi definisi Scrum. Definisi ini terdiri dari peran, peristiwa, artefak, dan aturan Scrum yang mengikatnya. Ken Schwaber dan Jeff Sutherland mengembangkan Scrum; Panduan Scrum ditulis dan disediakan oleh mereka. Bersama-sama, mereka berdiri di belakang Panduan Scrum.

Definisi Scrum Scrum (n): Kerangka kerja di mana orang dapat mengatasi masalah adaptif yang kompleks, sementara secara produktif dan kreatif memberikan produk dengan nilai setinggi mungkin.

Scrum adalah:

Ringan Mudah dimengerti Sulit dikuasai Scrum adalah kerangka proses yang telah digunakan untuk mengelola pekerjaan pada produk-produk kompleks sejak awal 1990-an. Scrum bukanlah proses, teknik, atau metode definitif. Sebaliknya, itu adalah kerangka kerja di mana Anda dapat menggunakan berbagai proses dan teknik. Scrum memperjelas kemanjuran relatif manajemen produk dan teknik kerja Anda sehingga Anda dapat terus meningkatkan produk, tim, dan lingkungan kerja.

Kerangka kerja Scrum terdiri dari Tim Scrum dan peran, acara, artefak, dan aturan yang terkait. Setiap komponen dalam kerangka kerja melayani tujuan tertentu dan sangat penting untuk keberhasilan dan penggunaan Scrum.

Aturan Scrum mengikat bersama peran, peristiwa, dan artefak, mengatur hubungan dan interaksi di antara mereka. Aturan Scrum dijelaskan di seluruh isi dokumen ini.

Taktik khusus untuk menggunakan kerangka kerja Scrum bervariasi dan dijelaskan di tempat lain.

Penggunaan Scrum Scrum awalnya dikembangkan untuk mengelola dan mengembangkan produk. Mulai awal 1990-an, Scrum telah digunakan secara luas, di seluruh dunia, untuk:

Meneliti dan mengidentifikasi pasar, teknologi, dan kapabilitas produk yang layak; Kembangkan produk dan perangkat tambahan; Lepaskan produk dan perangkat tambahan, sesering mungkin per hari; Mengembangkan dan mempertahankan Cloud (online, aman, sesuai permintaan) dan lingkungan operasional lainnya untuk penggunaan produk; dan, Mendukung dan memperbarui produk. Scrum telah digunakan untuk mengembangkan perangkat lunak, perangkat keras, perangkat lunak tertanam, jaringan fungsi berinteraksi, kendaraan otonom, sekolah, pemerintah, pemasaran, mengelola operasi organisasi dan hampir semua yang kita gunakan dalam kehidupan sehari-hari, sebagai individu dan masyarakat.

Karena kompleksitas teknologi, pasar, dan lingkungan serta interaksinya meningkat dengan cepat, utilitas Scrum dalam menangani kompleksitas terbukti setiap hari.

Scrum terbukti sangat efektif dalam transfer pengetahuan iteratif dan inkremental. Scrum sekarang banyak digunakan untuk produk, layanan, dan manajemen organisasi induk.

Inti dari Scrum adalah tim kecil orang. Tim individu sangat fleksibel dan adaptif. Kekuatan-kekuatan ini terus beroperasi dalam satu, beberapa, banyak, dan jaringan tim yang mengembangkan, melepaskan, mengoperasikan, dan mempertahankan pekerjaan dan produk kerja dari ribuan orang. Mereka berkolaborasi dan berinteroperasi melalui arsitektur pengembangan yang canggih dan lingkungan rilis target.

Ketika kata "berkembang" dan "pengembangan" digunakan dalam Panduan Scrum, mereka merujuk pada pekerjaan yang kompleks, seperti jenis-jenis yang diidentifikasi di atas.

Teori Scrum Scrum didirikan pada teori kontrol proses empiris, atau empirisme. Empirisme menegaskan bahwa pengetahuan berasal dari pengalaman dan membuat keputusan berdasarkan apa yang diketahui. Scrum menggunakan pendekatan iteratif, tambahan untuk mengoptimalkan prediktabilitas dan mengendalikan risiko. Tiga pilar menjunjung tinggi setiap implementasi kontrol proses empiris: transparansi, inspeksi, dan adaptasi.

Transparansi Aspek penting dari proses harus terlihat oleh mereka yang bertanggung jawab atas hasilnya. Transparansi mengharuskan aspek-aspek tersebut didefinisikan oleh standar umum sehingga pengamat berbagi pemahaman yang sama tentang apa yang dilihat.

Sebagai contoh:

Bahasa umum yang merujuk pada proses harus dibagikan oleh semua peserta; dan, Mereka yang melakukan pekerjaan dan mereka yang memeriksa kenaikan yang dihasilkan harus berbagi definisi umum tentang "Selesai". Inspeksi Pengguna Scrum harus sering memeriksa artefak Scrum dan maju menuju Tujuan Sprint untuk mendeteksi varian yang tidak diinginkan. Inspeksi mereka seharusnya tidak terlalu sering sehingga inspeksi menghalangi pekerjaan. Inspeksi paling bermanfaat ketika dilakukan dengan rajin oleh inspektur terlatih di titik kerja.

Adaptasi Jika seorang inspektur menentukan bahwa satu atau beberapa aspek dari proses menyimpang di luar batas yang dapat diterima, dan bahwa produk yang dihasilkan tidak dapat diterima, proses atau bahan yang sedang diproses harus disesuaikan. Penyesuaian harus dilakukan sesegera mungkin untuk meminimalkan penyimpangan lebih lanjut.

Scrum mengatur empat acara formal untuk inspeksi dan adaptasi, sebagaimana dijelaskan dalam bagian Acara Scrum dari dokumen ini:

Perencanaan Sprint Scrum harian Ulasan Sprint Sprint Retrospective Nilai Scrum Ketika nilai-nilai komitmen, keberanian, fokus, keterbukaan, dan rasa hormat diwujudkan dan dijalani oleh Tim Scrum, pilar-pilar transparansi, inspeksi, dan adaptasi Scrum hidup kembali dan membangun kepercayaan untuk semua orang. Anggota Tim Scrum belajar dan mengeksplorasi nilai-nilai tersebut saat mereka bekerja dengan acara, peran, dan artefak Scrum.

Penggunaan Scrum yang sukses tergantung pada orang yang menjadi lebih mahir dalam menjalankan kelima nilai ini. Orang-orang secara pribadi berkomitmen untuk mencapai tujuan Tim Scrum. Anggota Tim Scrum memiliki keberanian untuk melakukan hal yang benar dan mengatasi masalah sulit. Semua orang fokus pada pekerjaan Sprint dan tujuan Tim Scrum. Tim Scrum dan para pemangku kepentingannya sepakat untuk bersikap terbuka tentang semua pekerjaan dan tantangan dengan melakukan pekerjaan tersebut. Anggota Tim Scrum saling menghormati satu sama lain sebagai orang yang mampu dan mandiri.

Tim Scrum Tim Scrum terdiri dari Pemilik Produk, Tim Pengembangan, dan Master Scrum. Scrum Teams adalah organisasi mandiri dan lintas fungsional. Tim yang mengatur diri sendiri memilih cara terbaik untuk menyelesaikan pekerjaan mereka, daripada diarahkan oleh orang lain di luar tim. Tim lintas fungsi memiliki semua kompetensi yang dibutuhkan untuk menyelesaikan pekerjaan tanpa bergantung pada orang lain, bukan bagian dari tim. Model tim di Scrum dirancang untuk mengoptimalkan fleksibilitas, kreativitas, dan produktivitas. Tim Scrum telah membuktikan dirinya semakin efektif untuk semua penggunaan yang dinyatakan sebelumnya, dan semua pekerjaan yang kompleks.

Tim Scrum memberikan produk secara iteratif dan bertahap, memaksimalkan peluang untuk umpan balik. Pengiriman tambahan produk "Selesai" memastikan versi produk yang berpotensi berguna selalu tersedia.

Pemilik Produk Pemilik Produk bertanggung jawab untuk memaksimalkan nilai produk yang dihasilkan dari pekerjaan Tim Pengembangan. Bagaimana ini dilakukan dapat sangat bervariasi di seluruh organisasi, Tim Scrum, dan individu.

Pemilik Produk adalah satu-satunya orang yang bertanggung jawab untuk mengelola Product Backlog. Manajemen Product Backlog meliputi:

Dengan jelas mengekspresikan item Product Backlog; Memesan item dalam Product Backlog untuk mencapai tujuan dan misi terbaik; Mengoptimalkan nilai pekerjaan yang dilakukan Tim Pengembangan; Memastikan bahwa Product Backlog terlihat, transparan, dan jelas untuk semua, dan menunjukkan apa yang akan dilakukan oleh Tim Scrum selanjutnya; dan, Memastikan Tim Pengembangan memahami item dalam Product Backlog ke tingkat yang diperlukan. Pemilik Produk dapat melakukan pekerjaan di atas, atau meminta Tim Pengembangan melakukannya. Namun, Pemilik Produk tetap bertanggung jawab.

Pemilik Produk adalah satu orang, bukan komite. Pemilik Produk dapat mewakili keinginan komite dalam Product Backlog, tetapi mereka yang ingin mengubah prioritas item Product Backlog harus mengatasi Pemilik Produk.

Agar Pemilik Produk berhasil, seluruh organisasi harus menghormati keputusannya. Keputusan Pemilik Produk terlihat dalam konten dan pemesanan Backlog Produk. Tidak ada yang bisa memaksa Tim Pengembangan untuk bekerja dari serangkaian persyaratan yang berbeda.

Tim Pengembangan Tim Pengembangan terdiri dari para profesional yang melakukan pekerjaan menghasilkan Produk "Selesai" yang berpotensi dirilis yang dapat dirilis pada akhir setiap Sprint. Peningkatan "Selesai" diperlukan di Tinjauan Sprint. Hanya anggota Tim Pengembang yang membuat Peningkatan.

Tim Pengembangan disusun dan diberdayakan oleh organisasi untuk mengatur dan mengelola pekerjaan mereka sendiri. Sinergi yang dihasilkan mengoptimalkan efisiensi dan efektivitas Tim Pengembangan secara keseluruhan.

Tim Pengembangan memiliki karakteristik sebagai berikut:

Mereka mengatur diri sendiri. Tidak seorang pun (bahkan Master Scrum) yang memberi tahu Tim Pengembangan cara mengubah Product Backlog menjadi Peningkatan fungsi yang berpotensi untuk dirilis; Tim Pengembangan bersifat lintas fungsional, dengan semua keterampilan sebagai tim yang diperlukan untuk membuat Peningkatan produk; Scrum tidak mengakui gelar untuk anggota Tim Pengembangan, terlepas dari pekerjaan yang dilakukan oleh orang tersebut; Scrum tidak mengenali sub-tim dalam Tim Pengembangan, terlepas dari domain yang perlu ditangani seperti pengujian, arsitektur, operasi, atau analisis bisnis; dan, Anggota Tim Pengembangan Individu mungkin memiliki keterampilan khusus dan bidang fokus, tetapi akuntabilitas menjadi milik Tim Pengembangan secara keseluruhan. Ukuran Tim Pengembangan Ukuran Tim Pengembangan Optimal cukup kecil untuk tetap gesit dan cukup besar untuk menyelesaikan pekerjaan signifikan dalam Sprint. Kurang dari tiga anggota Tim Pengembangan mengurangi interaksi dan menghasilkan peningkatan produktivitas yang lebih kecil. Tim Pengembangan yang lebih kecil mungkin menghadapi kendala keterampilan selama Sprint, menyebabkan Tim Pengembangan tidak dapat memberikan Peningkatan yang berpotensi dirilis. Memiliki lebih dari sembilan anggota memerlukan koordinasi terlalu banyak. Tim Pengembangan Besar menghasilkan terlalu banyak kerumitan untuk proses empiris menjadi berguna. Peran Pemilik Produk dan Master Scrum tidak termasuk dalam penghitungan ini kecuali mereka juga menjalankan pekerjaan Sprint Backlog.

Master Scrum Scrum Master bertanggung jawab untuk mempromosikan dan mendukung Scrum sebagaimana didefinisikan dalam Panduan Scrum. Scrum Masters melakukan ini dengan membantu semua orang memahami teori, praktik, aturan, dan nilai-nilai Scrum.

Scrum Master adalah pelayan-pemimpin untuk Tim Scrum. Scrum Master membantu mereka yang berada di luar Tim Scrum memahami interaksi mereka dengan Tim Scrum mana yang bermanfaat dan mana yang tidak. Scrum Master membantu semua orang mengubah interaksi ini untuk memaksimalkan nilai yang diciptakan oleh Tim Scrum.

Layanan Master Scrum kepada Pemilik Produk Scrum Master melayani Pemilik Produk dalam beberapa cara, termasuk:

Memastikan bahwa sasaran, ruang lingkup, dan domain produk dipahami oleh semua orang di Tim Scrum sebaik mungkin; Menemukan teknik untuk manajemen Product Backlog yang efektif; Membantu Tim Scrum memahami perlunya item Product Backlog yang jelas dan ringkas; Memahami perencanaan produk dalam lingkungan empiris; Memastikan Pemilik Produk tahu bagaimana mengatur Product Backlog untuk memaksimalkan nilai; Memahami dan melatih ketangkasan; dan, Memfasilitasi acara Scrum sesuai permintaan atau kebutuhan. Layanan Master Scrum untuk Tim Pengembangan Scrum Master melayani Tim Pengembangan dalam beberapa cara, termasuk:

Melatih Tim Pengembangan dalam pengaturan mandiri dan lintas fungsi; Membantu Tim Pengembangan untuk menciptakan produk bernilai tinggi; Menghapus hambatan untuk kemajuan Tim Pengembangan; Memfasilitasi acara Scrum sesuai permintaan atau kebutuhan; dan, Melatih Tim Pengembangan dalam lingkungan organisasi di mana Scrum belum sepenuhnya diadopsi dan dipahami. Layanan Master Scrum untuk Organisasi Scrum Master melayani organisasi dalam beberapa cara, termasuk:

Memimpin dan melatih organisasi dalam penerapan Scrum; Merencanakan implementasi Scrum dalam organisasi; Membantu karyawan dan pemangku kepentingan memahami dan menetapkan Scrum dan pengembangan produk empiris; Menyebabkan perubahan yang meningkatkan produktivitas Tim Scrum; dan, Bekerja dengan Master Scrum lainnya untuk meningkatkan efektivitas penerapan Scrum dalam organisasi. Acara Scrum Acara yang ditentukan digunakan dalam Scrum untuk menciptakan keteraturan dan untuk meminimalkan kebutuhan pertemuan yang tidak didefinisikan dalam Scrum. Semua acara adalah acara kotak-waktu, sehingga setiap acara memiliki durasi maksimum. Setelah Sprint dimulai, durasinya ditetapkan dan tidak dapat dipersingkat atau diperpanjang. Acara yang tersisa dapat berakhir setiap kali tujuan acara tercapai, memastikan jumlah waktu yang tepat dihabiskan tanpa membiarkan limbah dalam proses.

Selain dari Sprint itu sendiri, yang merupakan wadah untuk semua acara lainnya, setiap acara di Scrum adalah kesempatan formal untuk memeriksa dan mengadaptasi sesuatu. Peristiwa ini secara khusus dirancang untuk memungkinkan transparansi dan inspeksi kritis. Kegagalan untuk memasukkan salah satu dari acara-acara ini menghasilkan transparansi yang berkurang dan merupakan kesempatan yang hilang untuk memeriksa dan beradaptasi.

Sprint Inti dari Scrum adalah Sprint, kotak waktu satu bulan atau kurang di mana "Selesai", dapat digunakan, Peningkatan produk yang berpotensi untuk dirilis dibuat. Sprint memiliki durasi yang konsisten selama upaya pengembangan. Sprint baru dimulai segera setelah kesimpulan dari Sprint sebelumnya.

Sprint mengandung dan terdiri dari Perencanaan Sprint, Scrum Harian, pekerjaan pengembangan, Ulasan Sprint, dan Retrospektif Sprint.

Selama Sprint:

Tidak ada perubahan yang akan membahayakan Tujuan Sprint; Sasaran mutu tidak menurun; dan, Lingkup dapat diklarifikasi dan dinegosiasikan ulang antara Pemilik Produk dan Tim Pengembangan karena lebih banyak dipelajari. Setiap Sprint dapat dianggap sebagai proyek dengan cakrawala tidak lebih dari satu bulan. Seperti halnya proyek, Sprint digunakan untuk mencapai sesuatu. Setiap Sprint memiliki tujuan apa yang akan dibangun, desain dan rencana fleksibel yang akan memandu pembangunannya, pekerjaan, dan peningkatan produk yang dihasilkan.

Sprint dibatasi hingga satu bulan kalender. Ketika cakrawala Sprint terlalu panjang, definisi apa yang sedang dibangun dapat berubah, kompleksitas mungkin meningkat, dan risiko dapat meningkat. Sprint memungkinkan prediktabilitas dengan memastikan inspeksi dan adaptasi kemajuan menuju Sasaran Sprint setidaknya setiap bulan kalender. Sprint juga membatasi risiko hingga satu bulan kalender dari biaya.

Membatalkan Sprint Sprint dapat dibatalkan sebelum kotak waktu Sprint selesai. Hanya Pemilik Produk yang memiliki wewenang untuk membatalkan Sprint, meskipun ia dapat melakukannya di bawah pengaruh dari para pemangku kepentingan, Tim Pengembangan, atau Master Scrum.

Sprint akan dibatalkan jika Tujuan Sprint menjadi usang. Ini mungkin terjadi jika perusahaan mengubah arah atau jika kondisi pasar atau teknologi berubah. Secara umum, Sprint harus dibatalkan jika tidak lagi masuk akal mengingat keadaan. Tetapi, karena durasi Sprint yang pendek, pembatalan jarang masuk akal.

Ketika Sprint dibatalkan, semua item Product Backlog yang selesai dan "Selesai" ditinjau. Jika bagian dari karya tersebut berpotensi untuk dirilis, Pemilik Produk biasanya menerimanya. Semua Item Backlog Produk yang tidak lengkap diperkirakan kembali dan dimasukkan ke dalam Product Backlog. Pekerjaan yang dilakukan pada mereka terdepresiasi dengan cepat dan harus sering diperkirakan ulang.

Pembatalan Sprint menghabiskan sumber daya, karena semua orang berkumpul kembali dalam Perencanaan Sprint lain untuk memulai Sprint lain. Pembatalan sprint sering menimbulkan trauma bagi Tim Scrum, dan sangat jarang terjadi.

Perencanaan Sprint Pekerjaan yang akan dilakukan dalam Sprint direncanakan pada Perencanaan Sprint. Rencana ini dibuat oleh karya kolaboratif dari seluruh Tim Scrum.

Perencanaan Sprint adalah kotak waktu untuk maksimum delapan jam untuk Sprint satu bulan. Untuk Sprint yang lebih pendek, acara biasanya lebih pendek. Scrum Master memastikan bahwa acara tersebut berlangsung dan para pelayan memahami tujuannya. Scrum Master mengajarkan Tim Scrum untuk menyimpannya di dalam kotak waktu.

Perencanaan Sprint menjawab yang berikut:

Apa yang bisa disampaikan dalam Peningkatan yang dihasilkan dari Sprint yang akan datang? Bagaimana pekerjaan yang dibutuhkan untuk menghasilkan Peningkatan akan tercapai? Topik Satu: Apa yang bisa dilakukan Sprint ini? Tim Pengembangan bekerja untuk memperkirakan fungsionalitas yang akan dikembangkan selama Sprint. Pemilik Produk membahas tujuan yang harus dicapai Sprint dan item Product Backlog yang, jika diselesaikan dalam Sprint, akan mencapai Tujuan Sprint. Seluruh Tim Scrum berkolaborasi untuk memahami pekerjaan Sprint.

Input untuk pertemuan ini adalah Product Backlog, Peningkatan produk terbaru, kapasitas yang diproyeksikan dari Tim Pengembangan selama Sprint, dan kinerja Tim Pengembangan sebelumnya. Jumlah item yang dipilih dari Product Backlog untuk Sprint hanya dimiliki oleh Tim Pengembangan. Hanya Tim Pengembang yang dapat menilai apa yang dapat dicapai selama Sprint mendatang.

Selama Perencanaan Sprint, Tim Scrum juga membuat Tujuan Sprint. Sasaran Sprint adalah tujuan yang akan dipenuhi dalam Sprint melalui implementasi Product Backlog, dan memberikan panduan kepada Tim Pengembang tentang mengapa ia membangun Peningkatan.

Topik Dua: bagaimana pekerjaan yang dipilih akan dilakukan? Setelah menetapkan Sprint Goal dan memilih item Product Backlog untuk Sprint, Tim Pengembangan memutuskan bagaimana ia akan membangun fungsionalitas ini menjadi Peningkatan produk "Selesai" selama Sprint. Item Product Backlog yang dipilih untuk Sprint ini ditambah rencana pengirimannya disebut Sprint Backlog.

Tim Pengembangan biasanya memulai dengan merancang sistem dan pekerjaan yang diperlukan untuk mengubah Product Backlog menjadi Peningkatan produk yang berfungsi. Pekerjaan mungkin dari berbagai ukuran, atau upaya yang diperkirakan. Namun, cukup banyak pekerjaan yang direncanakan selama Perencanaan Sprint untuk Tim Pengembangan untuk memperkirakan apa yang menurutnya dapat dilakukan di Sprint mendatang. Pekerjaan yang direncanakan untuk hari-hari pertama Sprint oleh Tim Pengembangan didekomposisi pada akhir pertemuan ini, seringkali menjadi unit satu hari atau kurang. Tim Pengembangan mengorganisir diri untuk melakukan pekerjaan dalam Sprint Backlog, baik selama Perencanaan Sprint dan sesuai kebutuhan sepanjang Sprint.

Pemilik Produk dapat membantu untuk memperjelas item Product Backlog yang dipilih dan melakukan trade-off. Jika Tim Pengembang menentukan bahwa ia memiliki terlalu banyak atau terlalu sedikit pekerjaan, ia dapat menegosiasikan kembali item Product Backlog yang dipilih dengan Pemilik Produk. Tim Pengembangan juga dapat mengundang orang lain untuk hadir untuk memberikan saran teknis atau domain.

Pada akhir Perencanaan Sprint, Tim Pengembangan harus dapat menjelaskan kepada Pemilik Produk dan Guru Scrum bagaimana ia bermaksud bekerja sebagai tim yang mengatur diri sendiri untuk mencapai Tujuan Sprint dan menciptakan Peningkatan yang diantisipasi.

Sasaran Sprint Sasaran Sprint adalah set tujuan untuk Sprint yang dapat dipenuhi melalui penerapan Product Backlog. Ini memberikan panduan kepada Tim Pengembangan tentang mengapa ia membangun Peningkatan. Ini dibuat selama pertemuan Perencanaan Sprint. Sasaran Sprint memberi Tim Pengembangan beberapa fleksibilitas mengenai fungsi yang diterapkan dalam Sprint. Item Product Backlog yang dipilih menghasilkan satu fungsi yang koheren, yang dapat menjadi Tujuan Sprint. Sasaran Sprint dapat berupa koherensi lain apa pun yang menyebabkan Tim Pengembangan bekerja bersama dan bukan pada inisiatif yang terpisah.

Saat Tim Pengembangan bekerja, ia mengingat Tujuan Sprint. Untuk memenuhi Tujuan Sprint, ia mengimplementasikan fungsionalitas dan teknologi. Jika pekerjaan ternyata berbeda dari yang diharapkan oleh Tim Pengembangan, mereka bekerja sama dengan Pemilik Produk untuk menegosiasikan ruang lingkup Sprint Backlog dalam Sprint.

Scrum harian The Scrum Harian adalah acara kotak waktu 15 menit untuk Tim Pengembangan. Scrum Harian diadakan setiap hari di Sprint. Pada saat itu, Tim Pengembangan berencana bekerja selama 24 jam ke depan. Ini mengoptimalkan kolaborasi tim dan kinerja dengan memeriksa pekerjaan sejak Scrum Harian terakhir dan memperkirakan pekerjaan Sprint yang akan datang. Scrum Harian diadakan pada waktu dan tempat yang sama setiap hari untuk mengurangi kompleksitas.

Tim Pengembangan menggunakan Scrum Harian untuk memeriksa kemajuan menuju Sprint Goal dan untuk memeriksa bagaimana kemajuan sedang menuju penyelesaian pekerjaan dalam Sprint Backlog. Scrum Harian mengoptimalkan kemungkinan bahwa Tim Pengembangan akan memenuhi Sasaran Sprint. Setiap hari, Tim Pengembangan harus memahami bagaimana niatnya untuk bekerja bersama sebagai tim yang mengatur diri sendiri untuk mencapai Tujuan Sprint dan menciptakan Peningkatan yang diantisipasi pada akhir Sprint.

Struktur pertemuan ditetapkan oleh Tim Pengembangan dan dapat dilakukan dengan cara yang berbeda jika berfokus pada kemajuan menuju Tujuan Sprint. Beberapa Tim Pengembangan akan menggunakan pertanyaan, beberapa akan lebih berbasis diskusi. Ini adalah contoh dari apa yang mungkin digunakan:

Apa yang saya lakukan kemarin yang membantu Tim Pengembangan memenuhi Sasaran Sprint? Apa yang akan saya lakukan hari ini untuk membantu Tim Pengembangan memenuhi Sasaran Sprint? Apakah saya melihat ada halangan yang menghalangi saya atau Tim Pengembangan untuk memenuhi Sasaran Sprint? Tim Pengembangan atau anggota tim sering bertemu segera setelah Scrum Harian untuk diskusi terperinci, atau untuk menyesuaikan, atau merencanakan ulang, sisa pekerjaan Sprint.

Scrum Master memastikan bahwa Tim Pengembangan mengadakan pertemuan, tetapi Tim Pengembangan bertanggung jawab untuk melakukan Scrum Harian. Scrum Master mengajarkan Tim Pengembangan untuk menjaga Scrum Harian dalam waktu 15 menit.

Scrum Harian adalah pertemuan internal untuk Tim Pengembangan. Jika orang lain hadir, Scrum Master memastikan bahwa mereka tidak mengganggu rapat.

Scrum harian meningkatkan komunikasi, menghilangkan rapat-rapat lain, mengidentifikasi halangan untuk pengembangan untuk dihapus, menyoroti dan mempromosikan pengambilan keputusan cepat, dan meningkatkan tingkat pengetahuan Tim Pengembang. Ini adalah pertemuan kunci inspeksi dan adaptasi.

Ulasan Sprint Tinjauan Sprint diadakan di akhir Sprint untuk memeriksa Peningkatan dan menyesuaikan Product Backlog jika perlu. Selama Tinjauan Sprint, Tim Scrum dan pemangku kepentingan berkolaborasi tentang apa yang dilakukan dalam Sprint. Berdasarkan hal itu dan perubahan apa pun pada Product Backlog selama Sprint, peserta berkolaborasi dalam hal-hal selanjutnya yang dapat dilakukan untuk mengoptimalkan nilai. Ini adalah pertemuan informal, bukan pertemuan status, dan presentasi Peningkatan ini dimaksudkan untuk memperoleh umpan balik dan mendorong kolaborasi.

Ini paling banyak merupakan pertemuan empat jam untuk Sprint satu bulan. Untuk Sprint yang lebih pendek, acara biasanya lebih pendek. Scrum Master memastikan bahwa acara tersebut berlangsung dan para peserta memahami tujuannya. Scrum Master mengajarkan semua orang yang terlibat untuk menyimpannya di dalam kotak waktu.

Ulasan Sprint mencakup elemen-elemen berikut:

Para peserta termasuk Tim Scrum dan pemangku kepentingan utama yang diundang oleh Pemilik Produk; Pemilik Produk menjelaskan item Product Backlog apa yang telah "Selesai" dan apa yang belum "Selesai"; Tim Pengembangan membahas apa yang berjalan dengan baik selama Sprint, masalah apa yang terjadi, dan bagaimana masalah tersebut diselesaikan; Tim Pengembangan menunjukkan pekerjaan yang telah dilakukan "Selesai" dan menjawab pertanyaan tentang Peningkatan; Pemilik Produk membahas Product Backlog sebagaimana adanya. Ia memproyeksikan kemungkinan target dan tanggal pengiriman berdasarkan kemajuan sampai saat ini (jika perlu); Seluruh grup berkolaborasi tentang apa yang harus dilakukan selanjutnya, sehingga Tinjauan Sprint memberikan masukan yang berharga untuk Perencanaan Sprint berikutnya; Tinjau bagaimana pasar atau potensi penggunaan produk mungkin telah mengubah hal apa yang paling berharga untuk dilakukan selanjutnya; dan, Tinjau garis waktu, anggaran, kemampuan potensial, dan pasar untuk rilis fungsionalitas atau kemampuan produk yang diantisipasi selanjutnya. Hasil dari Tinjauan Sprint adalah Product Backlog yang direvisi yang mendefinisikan kemungkinan item Product Backlog untuk Sprint berikutnya. Product Backlog juga dapat disesuaikan secara keseluruhan untuk memenuhi peluang baru.

Sprint Retrospective Sprint Retrospective adalah kesempatan bagi Tim Scrum untuk memeriksa dirinya sendiri dan membuat rencana untuk perbaikan yang akan diberlakukan selama Sprint berikutnya.

Retrospektif Sprint terjadi setelah Ulasan Sprint dan sebelum Perencanaan Sprint berikutnya. Ini paling banyak merupakan pertemuan tiga jam untuk Sprint satu bulan. Untuk Sprint yang lebih pendek, acara biasanya lebih pendek. Scrum Master memastikan bahwa acara tersebut berlangsung dan para pelayan memahami tujuannya.

Scrum Master memastikan bahwa pertemuan itu positif dan produktif. Scrum Master mengajarkan semua untuk menyimpannya di dalam kotak waktu. Scrum Master berpartisipasi sebagai anggota tim sejawat dalam pertemuan tersebut dari pertanggungjawaban atas proses Scrum.

Tujuan dari Sprint Retrospective adalah untuk:

Periksa bagaimana Sprint terakhir mengenai orang, hubungan, proses, dan alat; Identifikasi dan pesan item utama yang berjalan dengan baik dan potensi perbaikan; dan, Buat rencana untuk menerapkan peningkatan pada cara Tim Scrum melakukan tugasnya. Scrum Master mendorong Tim Scrum untuk meningkatkan, dalam kerangka proses Scrum, proses pengembangan dan praktiknya untuk membuatnya lebih efektif dan menyenangkan untuk Sprint berikutnya. Selama setiap Sprint Retrospective, Tim Scrum merencanakan cara untuk meningkatkan kualitas produk dengan meningkatkan proses kerja atau mengadaptasi definisi "Selesai", jika sesuai dan tidak bertentangan dengan standar produk atau organisasi.

Pada akhir Retrospektif Sprint, Tim Scrum harus telah mengidentifikasi perbaikan yang akan diterapkan dalam Sprint berikutnya. Menerapkan perbaikan ini di Sprint berikutnya adalah adaptasi terhadap inspeksi Tim Scrum itu sendiri. Meskipun perbaikan dapat diimplementasikan kapan saja, Sprint Retrospective menyediakan kesempatan formal untuk fokus pada inspeksi dan adaptasi.

Artefak Scrum Artefak Scrum mewakili pekerjaan atau nilai untuk memberikan transparansi dan peluang untuk inspeksi dan adaptasi. Artefak yang didefinisikan oleh Scrum dirancang khusus untuk memaksimalkan transparansi informasi utama sehingga setiap orang memiliki pemahaman yang sama tentang artefak.

Product Backlog Product Backlog adalah daftar semua hal yang diketahui dibutuhkan dalam produk. Ini adalah sumber tunggal persyaratan untuk setiap perubahan yang dilakukan pada produk. Pemilik Produk bertanggung jawab atas Product Backlog, termasuk konten, ketersediaan, dan pemesanannya.

Product Backlog tidak pernah lengkap. Perkembangan paling awal memaparkan persyaratan-persyaratan yang pada awalnya diketahui dan paling dipahami. Product Backlog berkembang sebagai produk dan lingkungan di mana ia akan digunakan berkembang. Product Backlog bersifat dinamis; itu terus berubah untuk mengidentifikasi produk apa yang harus sesuai, kompetitif, dan bermanfaat. Jika suatu produk ada, Product Backlog-nya juga ada.

Product Backlog mencantumkan semua fitur, fungsi, persyaratan, peningkatan, dan perbaikan yang merupakan perubahan yang harus dilakukan terhadap produk dalam rilis mendatang. Item Product Backlog memiliki atribut deskripsi, urutan, perkiraan, dan nilai. Item Product Backlog sering menyertakan deskripsi pengujian yang akan membuktikan kelengkapannya ketika "Selesai".

Ketika suatu produk digunakan dan memperoleh nilai, dan pasar memberikan umpan balik, Product Backlog menjadi daftar yang lebih besar dan lebih lengkap. Persyaratan tidak pernah berhenti berubah, sehingga Product Backlog adalah artefak yang hidup. Perubahan dalam persyaratan bisnis, kondisi pasar, atau teknologi dapat menyebabkan perubahan dalam Product Backlog.

Multiple Scrum Teams sering bekerja bersama untuk produk yang sama. Satu Product Backlog digunakan untuk menggambarkan pekerjaan yang akan datang pada produk. Atribut Backlog Produk yang mengelompokkan item kemudian dapat digunakan.

Penyempurnaan Product Backlog adalah tindakan menambahkan detail, perkiraan, dan memesan item di Product Backlog. Ini adalah proses yang sedang berlangsung di mana Pemilik Produk dan Tim Pengembangan berkolaborasi pada detail item Product Backlog. Selama penyempurnaan Product Backlog, item ditinjau dan direvisi. Tim Scrum memutuskan bagaimana dan kapan penyempurnaan dilakukan. Perbaikan biasanya mengkonsumsi tidak lebih dari 10% dari kapasitas Tim Pengembangan. Namun, item Product Backlog dapat diperbarui kapan saja oleh Pemilik Produk atau atas kebijakan Pemilik Produk.

Item Product Backlog yang lebih tinggi biasanya lebih jelas dan lebih rinci daripada yang dipesan lebih rendah. Estimasi yang lebih tepat dibuat berdasarkan kejelasan yang lebih besar dan peningkatan detail; semakin rendah urutannya, semakin sedikit detailnya. Item Product Backlog yang akan menempati Tim Pengembangan untuk Sprint yang akan datang disempurnakan sehingga setiap item yang masuk akal bisa "Selesai" di dalam kotak waktu Sprint. Item Product Backlog yang dapat "Dilakukan" oleh Tim Pengembangan dalam satu Sprint dianggap "Siap" untuk dipilih dalam Perencanaan Sprint. Item Product Backlog biasanya memperoleh tingkat transparansi ini melalui kegiatan pemurnian yang dijelaskan di atas.

Tim Pengembangan bertanggung jawab untuk semua perkiraan. Pemilik Produk dapat memengaruhi Tim Pengembangan dengan membantunya memahami dan memilih trade-off, tetapi orang-orang yang akan melakukan pekerjaan membuat perkiraan akhir.

Memantau Kemajuan Menuju Tujuan Kapan saja, total pekerjaan yang tersisa untuk mencapai tujuan dapat disimpulkan. Pemilik Produk melacak total pekerjaan ini yang tersisa setidaknya setiap Ulasan Sprint. Pemilik Produk membandingkan jumlah ini dengan pekerjaan yang tersisa di Ulasan Sprint sebelumnya untuk menilai kemajuan dalam menyelesaikan pekerjaan yang diproyeksikan pada waktu yang diinginkan untuk tujuan tersebut. Informasi ini dibuat transparan untuk semua pemangku kepentingan.

Berbagai praktik proyektif berdasarkan tren telah digunakan untuk memperkirakan kemajuan, seperti burn-down, burn-up, atau aliran kumulatif. Ini terbukti bermanfaat. Namun, ini tidak menggantikan pentingnya empirisme. Dalam lingkungan yang kompleks, apa yang akan terjadi tidak diketahui. Hanya apa yang sudah terjadi yang dapat digunakan untuk pengambilan keputusan berwawasan ke depan.

Sprint Backlog Sprint Backlog adalah sekumpulan item Product Backlog yang dipilih untuk Sprint, ditambah rencana untuk mengirimkan Peningkatan produk dan mewujudkan Sasaran Sprint. Sprint Backlog adalah perkiraan oleh Tim Pengembangan tentang fungsionalitas apa yang akan ada dalam Peningkatan berikutnya dan pekerjaan yang diperlukan untuk mengantarkan fungsionalitas itu ke dalam Peningkatan "Selesai".

Sprint Backlog menjadikan semua pekerjaan yang diidentifikasi oleh Tim Pengembangan sebagai perlu untuk memenuhi Tujuan Sprint. Untuk memastikan peningkatan berkelanjutan, ini mencakup setidaknya satu peningkatan proses prioritas tinggi yang diidentifikasi dalam pertemuan Retrospektif sebelumnya.

Sprint Backlog adalah rencana dengan detail yang cukup sehingga perubahan dalam kemajuan dapat dipahami dalam Scrum Harian. Tim Pengembangan memodifikasi Sprint Backlog di seluruh Sprint, dan Sprint Backlog muncul selama Sprint. Munculnya ini terjadi ketika Tim Pengembang bekerja melalui rencana dan belajar lebih banyak tentang pekerjaan yang diperlukan untuk mencapai Tujuan Sprint.

Karena pekerjaan baru diperlukan, Tim Pengembangan menambahkannya ke Sprint Backlog. Saat pekerjaan dilakukan atau diselesaikan, perkiraan sisa pekerjaan diperbarui. Ketika elemen-elemen dari rencana dianggap tidak perlu, mereka dihapus. Hanya Tim Pengembang yang dapat mengubah Sprint Backlog selama Sprint. Sprint Backlog adalah gambar pekerjaan nyata yang sangat nyata yang direncanakan oleh Tim Pengembangan untuk diselesaikan selama Sprint, dan itu semata-mata milik Tim Pengembangan.

Memantau Perkembangan Sprint Kapan saja dalam Sprint, total pekerjaan yang tersisa dalam Sprint Backlog dapat dijumlahkan. Tim Pengembangan melacak total pekerjaan ini yang tersisa setidaknya untuk setiap Scrum Harian untuk memproyeksikan kemungkinan mencapai Sasaran Sprint. Dengan melacak sisa pekerjaan di seluruh Sprint, Tim Pengembangan dapat mengelola kemajuannya.

Kenaikan Peningkatan adalah jumlah semua item Product Backlog yang diselesaikan selama Sprint dan nilai kenaikan semua Sprint sebelumnya. Pada akhir Sprint, Peningkatan baru harus "Selesai," yang berarti harus dalam kondisi dapat digunakan dan memenuhi definisi Tim Scrum tentang "Selesai". Selisih adalah badan yang dapat diperiksa, dilakukan pekerjaan yang mendukung empirisme pada akhir Sprint. Peningkatan adalah langkah menuju visi atau tujuan. Peningkatan harus dalam kondisi yang dapat digunakan terlepas dari apakah Pemilik Produk memutuskan untuk melepaskannya.

Transparansi artefak Scrum mengandalkan transparansi. Keputusan untuk mengoptimalkan nilai dan mengendalikan risiko dibuat berdasarkan persepsi artefak. Sejauh transparansi lengkap, keputusan-keputusan ini memiliki dasar yang kuat. Sejauh artefak tidak sepenuhnya transparan, keputusan ini dapat cacat, nilai dapat berkurang dan risiko dapat meningkat.

Scrum Master harus bekerja dengan Pemilik Produk, Tim Pengembangan, dan pihak-pihak terkait lainnya untuk memahami jika artefak sepenuhnya transparan. Ada praktik untuk mengatasi transparansi yang tidak lengkap; Scrum Master harus membantu semua orang menerapkan praktik yang paling tepat tanpa adanya transparansi penuh. Seorang Scrum Master dapat mendeteksi transparansi yang tidak lengkap dengan memeriksa artefak, merasakan pola, mendengarkan dengan cermat apa yang dikatakan, dan mendeteksi perbedaan antara hasil yang diharapkan dan hasil nyata.

Tugas Scrum Master adalah bekerja dengan Tim Scrum dan organisasi untuk meningkatkan transparansi artefak. Pekerjaan ini biasanya melibatkan pembelajaran, meyakinkan, dan perubahan. Transparansi tidak terjadi dalam semalam, tetapi merupakan jalan.

Definisi "Selesai" Ketika item Product Backlog atau Increment dideskripsikan sebagai "Selesai", semua orang harus mengerti apa artinya "Selesai". Meskipun ini mungkin sangat bervariasi per Tim Scrum, anggota harus memiliki pemahaman bersama tentang apa artinya pekerjaan harus lengkap, untuk memastikan transparansi. Ini adalah definisi "Selesai" untuk Tim Scrum dan digunakan untuk menilai kapan pekerjaan selesai pada Peningkatan produk.

Definisi yang sama memandu Tim Pengembangan untuk mengetahui berapa banyak item Product Backlog yang dapat dipilih selama Perencanaan Sprint. Tujuan dari masing-masing Sprint adalah untuk memberikan Peningkatan fungsi yang berpotensi untuk dirilis yang sesuai dengan definisi "Selesai" Tim Scrum saat ini.

Tim Pengembangan memberikan Peningkatan fungsi produk setiap Sprint. Peningkatan ini dapat digunakan, sehingga Pemilik Produk dapat memilih untuk segera merilisnya. Jika definisi "Selesai" untuk kenaikan adalah bagian dari konvensi, standar, atau pedoman organisasi pengembangan, semua Tim Scrum harus mengikutinya sebagai minimum.

Jika "Selesai" untuk penambahan bukan merupakan konvensi dari organisasi pengembangan, Tim Pengembangan dari Tim Scrum harus mendefinisikan definisi "Selesai" yang sesuai untuk produk. Jika ada beberapa Tim Scrum yang bekerja pada sistem atau rilis produk, Tim Pengembangan pada semua Tim Scrum harus saling mendefinisikan definisi "Selesai".

Setiap Peningkatan merupakan tambahan untuk semua Peningkatan sebelumnya dan diuji secara menyeluruh, memastikan bahwa semua Peningkatan akan bekerja bersama.

Ketika Tim Scrum matang, diharapkan definisi "Selesai" mereka akan diperluas untuk mencakup kriteria yang lebih ketat untuk kualitas yang lebih tinggi. Definisi baru, seperti yang digunakan, dapat mengungkap pekerjaan yang harus dilakukan dalam penambahan "Selesai" sebelumnya. Setiap produk atau sistem harus memiliki definisi "Selesai" yang merupakan standar untuk setiap pekerjaan yang dilakukan di atasnya.

Scrum gratis dan ditawarkan dalam Panduan ini. Peran, acara, artefak, dan aturan Scrum tidak dapat diubah dan meskipun hanya menerapkan sebagian Scrum yang mungkin, hasilnya bukan Scrum. Scrum hanya ada secara keseluruhan dan berfungsi dengan baik sebagai wadah untuk teknik, metodologi, dan praktik lainnya.

Sumber : http://www.scrum.co.id/courses/indonesia/19173-pelatihan-sertifikasi-professional-scrum-product-owner-jakarta-june-2019