Bahasa Indonesia
Scrum Master vs Product Owner: Perbandingan Peran
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Product Owner bertanggung jawab memaksimalkan nilai produk dan mengelola apa yang masuk ke backlog: "apa" dan "mengapa". Scrum Master bertanggung jawab atas efektivitas Scrum Team dan cara tim bekerja: "bagaimana", bukan "apa". Jika dua hal itu tertukar, hampir semua kebingungan lain tentang kedua pekerjaan ini akan mengikuti.
Kebingungan ini cukup umum sehingga perlu dipertegas sejak awal, karena dalam praktik kedua pekerjaan itu terus-menerus tercampur, baik ketika Scrum Master diam-diam menyusun ulang backlog karena Product Owner lambat, maupun ketika Product Owner menjalankan Daily Scrum seperti rapat status karena tidak ada yang memberi tahu mereka.
Fakta Utama
- Scrum Guide 2020 menyatakan bahwa Scrum "mendefinisikan tiga akuntabilitas spesifik dalam Scrum Team: Developers, Product Owner, dan Scrum Master," bahasa yang menggantikan istilah "peran" pada edisi-edisi sebelumnya.
- Menurut Guide tersebut, Product Owner "bertanggung jawab memaksimalkan nilai produk yang dihasilkan dari pekerjaan Scrum Team," sedangkan Scrum Master "bertanggung jawab atas efektivitas Scrum Team."
- Scrum Team "biasanya terdiri dari 10 orang atau kurang," menurut Scrum Guide 2020, cukup kecil sehingga kedua akuntabilitas berada di dalam satu tim, bukan di lapisan manajemen di atasnya.
- Large-Scale Scrum (LeSS) mempertahankan tepat satu Product Owner untuk semua tim yang membangun satu produk, dengan alasan bahwa membagi backlog ke beberapa Product Owner akan memecah prioritas.
Dua akuntabilitas, bukan dua peran
Kebanyakan perbandingan kedua posisi ini dimulai dari tempat yang salah: daftar simetris "Scrum Master melakukan X, Product Owner melakukan Y," seolah-olah keduanya berada di jalur yang setara dan paralel. Kenyataannya tidak begitu, dan Scrum Guide 2020 bahkan mengubah pilihan katanya untuk menegaskan hal itu. Edisi-edisi sebelumnya menyebut Product Owner, Scrum Master, dan Developers sebagai "peran". Edisi terkini tidak memakai kata itu untuk satu pun dari mereka. Guide menyatakan bahwa Scrum "mendefinisikan tiga akuntabilitas spesifik dalam Scrum Team," sebuah perubahan yang disengaja dan masih sering keliru dipakai oleh penjelasan lain yang kembali ke kata "peran" karena kebiasaan.
Pilihan kata ini penting. "Peran" menyiratkan uraian pekerjaan: sekumpulan tugas yang diberikan kepada seseorang. "Akuntabilitas" menyiratkan sesuatu yang lebih sempit dan lebih berat: satu orang mempertanggungjawabkan sebuah hasil, terlepas dari apakah ia sendiri yang mengerjakannya. Dengan pembacaan itu, perbedaan antara kedua pekerjaan ini berhenti menjadi daftar tugas dan berubah menjadi pertanyaan tentang apa yang harus dipertanggungjawabkan masing-masing orang ketika ada yang salah.
Jika Anda baru mempelajari bagaimana Scrum tersusun sebagai framework, bacalah itu lebih dulu sebelum perbandingan ini, karena semua uraian di bawah mengasumsikan adanya Sprint, tiga artefak, dan Scrum Team kecil yang mengelola diri sendiri. Kedua akuntabilitas ini hanya ada di dalam struktur tersebut. Tanpa Scrum, kedua jabatan itu tidak lagi bermakna spesifik.
Scrum Master vs Product Owner sekilas
| Scrum Master | Product Owner | |
|---|---|---|
| Bertanggung jawab atas | Efektivitas Scrum Team, cara tim bekerja | Memaksimalkan nilai produk, apa yang dibangun dan dalam urutan apa |
| Artefak utama | Tidak memiliki satu pun secara langsung; mendukung ketiganya (Product Backlog, Sprint Backlog, Increment) | Product Backlog |
| Siapa yang dilayani | Developers, Product Owner, dan organisasi secara lebih luas | Pemangku kepentingan, pelanggan, dan Developers yang membangun apa yang mereka urutkan |
| Event utama | Memfasilitasi setiap event Scrum; tidak memiliki isinya | Hadir di setiap event; mengarahkan isi Sprint Planning dan Sprint Review |
| Keberhasilan diukur dari | Hambatan yang lebih sedikit, event yang lebih sehat, pengelolaan diri tim yang lebih baik | Nilai yang diberikan: kesehatan backlog, kepercayaan pemangku kepentingan, hasil produk |
| Pola kegagalan khas | Menjadi penjadwal rapat atau pelapor status tanpa dampak coaching | Menjadi perantara penulis tiket tanpa wewenang nyata untuk menolak |
| Tempat akuntabilitas berada | Di dalam tim dan prosesnya | Di dalam produk dan backlog |
Apa yang sebenarnya menjadi akuntabilitas Product Owner
Menurut Guide, "Product Owner juga bertanggung jawab atas pengelolaan Product Backlog yang efektif," yang terurai menjadi empat tugas spesifik: mengembangkan dan mengomunikasikan Product Goal, membuat dan mengomunikasikan item backlog, mengurutkan backlog, serta menjaganya tetap transparan dan dipahami. Dalam seminggu nyata, daftar itu lebih mirip rangkaian keputusan berdasarkan penilaian daripada urusan administrasi.
| Bahasa Scrum Guide | Wujudnya dari minggu ke minggu |
|---|---|
| "Mengembangkan dan mengomunikasikan Product Goal secara eksplisit" | Menulis (dan menjelaskan ulang) satu paragraf yang menyatakan apa yang ingin dicapai produk ini berikutnya, sehingga setiap percakapan backlog refinement punya saringan |
| "Membuat dan mengomunikasikan item Product Backlog dengan jelas" | Mengubah permintaan pemangku kepentingan menjadi cerita pengguna yang tersusun baik dengan hasil yang jelas, bukan sekadar nama fitur |
| "Mengurutkan item Product Backlog" | Berkata tidak, secara terbuka, kepada pemangku kepentingan yang paling vokal di ruangan, karena ada hal lain yang lebih bernilai saat ini |
| "Memastikan Product Backlog transparan, terlihat, dan dipahami" | Menjaga backlog cukup mudah dibaca sehingga seorang Developer bisa mengambil item berikutnya tanpa rapat untuk menafsirkannya |
Dua kalimat dalam Guide bekerja lebih keras daripada kesan awalnya. Yang pertama: "Product Owner dapat mengerjakan hal-hal di atas atau mendelegasikan tanggung jawabnya kepada pihak lain. Apa pun pilihannya, Product Owner tetap bertanggung jawab." Product Owner boleh meminta orang lain menulis cerita pengguna atau menjalankan proses intake. Namun akuntabilitasnya sendiri tidak bisa diserahkan, artinya tanggung jawab tetap pada mereka walaupun pena bukan di tangan mereka.
Yang kedua: "agar Product Owner berhasil, seluruh organisasi harus menghormati keputusan mereka." Itu bukan basa-basi; itu persyaratan struktural. Product Owner yang urutan backlog-nya dibatalkan oleh siapa pun yang mengadu kepada seorang VP sebenarnya tidak bertanggung jawab atas apa pun, apa pun jabatannya. Jika hal itu terjadi di tim Anda, jabatan tersebut hanya hiasan.
Apa yang sebenarnya menjadi akuntabilitas Scrum Master
Akuntabilitas Scrum Master terbagi menjadi layanan kepada tiga pihak berbeda: Scrum Team, Product Owner, dan organisasi. Pembagian tiga arah ini mudah terlewat jika Anda hanya menganggap Scrum Master sebagai "orang yang menjalankan stand-up".
| Melayani | Bahasa Scrum Guide | Sehari-hari |
|---|---|---|
| Scrum Team | "Melatih anggota tim dalam pengelolaan diri dan lintas fungsi"; "mengupayakan penyingkiran hambatan" | Duduk bersama Developer yang terhambat untuk mengurai ketergantungan, bukan sekadar mencatat hambatan itu dalam laporan status |
| Scrum Team | "Memastikan semua event Scrum berlangsung dan bersifat positif, produktif, serta tetap dalam batas waktu" | Menjaga Daily Scrum tetap 15 menit dan mengarahkannya kembali menjadi percakapan perencanaan, bukan pembacaan status |
| Product Owner | "Membantu menemukan teknik untuk pendefinisian Product Goal dan pengelolaan Product Backlog yang efektif" | Menyarankan format refinement yang lebih ringan ketika item mulai menumpuk tanpa penyempurnaan |
| Organisasi | "Memimpin, melatih, dan membimbing organisasi dalam adopsi Scrum"; "menyingkirkan penghalang antara pemangku kepentingan dan Scrum Team" | Menolak ketika seorang eksekutif mencoba menyelipkan pekerjaan baru ke dalam sprint di tengah siklus, sehingga tim tidak harus melawan sendirian |
Perhatikan apa yang tidak ada dalam daftar itu: menulis laporan status untuk manajemen, memiliki tanggal pengiriman, atau memutuskan apa yang dibangun tim. Tugas-tugas itu terus-menerus terserap ke dalam peran ini dalam praktik, dan begitulah seorang Scrum Master berubah menjadi koordinator proyek dengan jabatan berbeda. Menurut Guide, akuntabilitasnya adalah efektivitas tim, titik, bukan fungsi pelaporan yang ditempelkan padanya.
Di mana keduanya bertabrakan, dan cara tim yang sehat menyelesaikannya
Bagian inilah yang dilewati kebanyakan perbandingan, padahal inilah yang paling penting dalam keseharian. Kedua akuntabilitas ini tidak dirancang untuk saling berlawanan, tetapi cukup sering menarik ke arah berbeda sehingga gesekan itu wajar, bukan tanda ada yang rusak.
| Titik gesek | Naluri Product Owner | Naluri Scrum Master | Cara tim yang sehat menyelesaikannya |
|---|---|---|---|
| Pemangku kepentingan meminta pekerjaan baru disisipkan di tengah sprint | Ingin cepat mengiyakan agar hubungan tetap hangat | Ingin melindungi Sprint Goal dan fokus tim | Pertukarannya dibahas bersama seluruh tim, tidak diputuskan sepihak; lingkup baru menunggu Sprint Planning berikutnya kecuali semua setuju menukar sesuatu |
| Backlog refinement terus berlarut | Ingin menyelesaikan lebih banyak item agar backlog tetap mendahului tim | Ingin melindungi batas waktu dan energi tim | Scrum Master mengusulkan format yang lebih ringan (batch lebih kecil, bahan bacaan asinkron) alih-alih sekadar memotong rapat dan membiarkan backlog menipis |
| Pemangku kepentingan mencoba langsung ke Developers, melewati backlog | Khawatir kehilangan kendali atas prioritas | Khawatir tim ditarik ke dua arah sekaligus | Scrum Master mengarahkan pemangku kepentingan ke Product Owner, secara konsisten dan terbuka, sampai hal itu berhenti terjadi |
| Sprint Review memperlihatkan tim berkomitmen berlebihan | Ingin mengelola percakapan dengan pemangku kepentingan tentang apa yang meleset | Ingin retrospektif mengungkap mengapa estimasinya salah | Keduanya menyelesaikan separuh: Product Owner memegang pesan kepada pemangku kepentingan, Scrum Master memegang perbaikan proses, dan tidak ada yang melewatkan bagiannya |
| Definition of Done diam-diam dilonggarkan demi mengejar tanggal | Ingin merilis kemajuan yang terlihat sebelum tenggat | Bertanggung jawab agar tim memenuhi Definition of Done miliknya sendiri | Scrum Master memiliki klaim yang lebih kuat di sini. Standar mutu yang disepakati seluruh tim bukan target yang boleh dilepas Product Owner secara sepihak |
Pola di balik kelima baris itu: tugas Product Owner adalah memperjuangkan nilai dan bergerak cepat, sedangkan tugas Scrum Master adalah melindungi kapasitas tim untuk benar-benar menyampaikan nilai itu secara berkelanjutan. Tidak ada naluri yang salah dengan sendirinya. Gesekan itu adalah sistem yang bekerja, bukan gagal, selama salah satu pihak tidak sekadar menimpa akuntabilitas pihak lain demi menghilangkan ketegangan.
Event Scrum satu per satu: siapa melakukan apa
Kedua akuntabilitas hadir di setiap event, tetapi dengan sikap yang berbeda. Satu membawa isi, yang lain melindungi wadah tempat isi itu berlangsung.
| Event | Product Owner | Scrum Master |
|---|---|---|
| Sprint Planning | Membawa bagian atas backlog yang terurut dan usulan Sprint Goal; menjawab pertanyaan Developer tentang maksudnya | Memfasilitasi batas waktu dan memastikan Sprint Goal benar-benar disepakati, bukan sekadar diasumsikan |
| Daily Scrum | Kehadiran bersifat opsional menurut Guide; biasanya tidak hadir kecuali diundang untuk menjawab hal tertentu | Tidak wajib hadir juga, tetapi membimbing Developers agar tetap menjadikannya sesi perencanaan, bukan laporan status ke atas |
| Backlog refinement | Memimpin sesi: mengurutkan item, memperjelas kriteria penerimaan, memaparkan alasan nilai untuk yang berikutnya | Memfasilitasi format dan batas waktu; turun tangan jika refinement berubah menjadi menggugat ulang keputusan yang sudah final |
| Sprint Review | Memaparkan apa yang dirilis, mengumpulkan umpan balik pemangku kepentingan, memperbarui backlog berdasarkan apa yang dipelajari | Menjaga event tetap sebagai sesi kerja, bukan demo satu arah atau penilaian kinerja tim |
| Sprint Retrospective | Hadir sebagai anggota tim; keputusannya sendiri boleh menerima umpan balik seperti keputusan siapa pun | Memfasilitasi format dan tindak lanjutnya; bertanggung jawab agar tim benar-benar membaik, bukan hanya membicarakannya |
Bisakah satu orang memegang keduanya?
Kadang bisa, dan biasanya tidak bertahan lama. Kedua akuntabilitas ini secara struktural saling menarik: tugas Product Owner menghargai sikap mengiyakan nilai dan bergerak cepat, sedangkan tugas Scrum Master menghargai perlindungan tempo tim dan penolakan ketika kecepatan mengancam mutu. Jika kedua insentif itu ditaruh di kepala satu orang, salah satu sisi hampir selalu menang secara otomatis, biasanya sisi yang tekanannya lebih keras dan lebih mendesak (tenggat pemangku kepentingan biasanya mengalahkan percakapan coaching yang kurang mencolok).
Klausul delegasi dalam Guide justru membuat peran gabungan ini lebih buruk, bukan lebih baik. Mendelegasikan tugas tidak mengurangi total akuntabilitas, hanya memusatkan dua jenis akuntabilitas terpisah ke dalam satu kalender. Gabungan Product Owner dan Scrum Master bukan mengerjakan separuh dari dua pekerjaan; ia bertanggung jawab penuh atas keduanya, dengan jam kerja satu orang.
Perlu dibedakan dari jenis pemadatan peran lain. Large-Scale Scrum (LeSS) sengaja mempertahankan satu Product Owner untuk banyak tim yang membangun satu produk, tetapi karena alasan yang berlawanan: agar prioritas tidak terpecah di antara backlog yang bersaing, bukan untuk menghemat tenaga kerja. Itu satu Product Owner yang mencakup lebih banyak tim, bukan satu orang yang mencakup dua akuntabilitas berbeda. Jika organisasi Anda berkembang melampaui satu tim, LeSS dan pendekatan penskalaan serupa layak dibaca sebelum ada yang berimprovisasi menciptakan peran gabungan karena terpaksa.
| Di mana penggabungan dicoba | Mengapa menggoda | Mengapa biasanya gagal |
|---|---|---|
| Startup sangat kecil, satu tim, satu produk | Anggaran hanya cukup untuk satu gaji, bukan dua | Orang tersebut akhirnya kurang melayani pemangku kepentingan atau kurang membimbing tim, karena kedua pekerjaan berebut jam yang sama |
| Tim alat internal dengan sedikit pemangku kepentingan eksternal | Tekanan luar yang rendah pada sisi Product Owner membuat sisi Scrum Master mendominasi secara otomatis | Disiplin backlog melorot, karena "tidak ada pemangku kepentingan mendesak" diam-diam berubah menjadi "tidak ada disiplin backlog" |
| Tim yang baru mengenal Scrum | Kedua akuntabilitas belum terasa terisi penuh, sehingga penggabungan tampak efisien di atas kertas | Tim tidak pernah melihat apa yang sebenarnya dilakukan Scrum Master yang memfasilitasi dengan benar, karena orang gabungan itu cenderung mengerjakan backlog saat tenggat menekan |
| Seorang developer memegang keduanya di samping pekerjaan coding | Efisiensi jumlah personel maksimum | Penyingkiran hambatan dan pengelolaan pemangku kepentingan sama-sama kalah dari pengiriman kode, karena tidak satu pun menjadi identitas utama orang itu |
Di mana penggabungan masih bertahan: tim yang sangat kecil dan rendah konflik, diperlakukan secara eksplisit sebagai pengaturan sementara, dan ditinjau ulang begitu tim atau daftar pemangku kepentingan bertambah. Kegagalannya bukan pada mencobanya. Kegagalannya adalah tidak pernah berencana untuk memisahkannya kembali.
Scrum Master dan Product Owner vs Project Manager dan Product Manager
Baik Scrum Master maupun Product Owner bukanlah project manager dengan nama lain, meskipun keduanya diam-diam menyerap sebagian pekerjaan itu dalam praktik. Dan Product Owner sudah memiliki perbandingan lengkap dengan Product Manager di tempat lain: bacalah Product Owner vs Product Manager untuk memahami asimetri antara akuntabilitas dan jabatan yang menjadi sumber kebingungan itu (singkatnya: Product Owner didefinisikan oleh satu dokumen, sedangkan Product Manager tidak didefinisikan oleh dokumen mana pun).
Perbandingan Scrum Master dengan project manager lebih jelas pemisahannya, karena kedua pekerjaan ini nyaris tidak tumpang tindih dalam apa yang mereka miliki.
| Scrum Master | Project Manager | |
|---|---|---|
| Didefinisikan oleh | Scrum Guide, satu standar eksternal | Tidak ada satu standar pemilik; PMBOK dari PMI adalah rujukan terdekat, tetapi jabatan ini ada dengan atau tanpa itu |
| Memiliki jadwal? | Tidak. Tim mengelola pekerjaannya sendiri di dalam Sprint | Sering, terutama dalam lingkungan tingkat program atau yang mendekati waterfall |
| Wewenang atas lingkup | Tidak ada. Lingkup milik Product Owner | Sering, bersama anggaran dan jadwal |
| Melapor status ke atas? | Bukan tugasnya. Sprint Review dan artefak melakukannya secara transparan, tanpa laporan terpisah | Sering, melalui laporan status dan komite pengarah |
| Ada di luar Scrum? | Tidak | Ya, di hampir semua metodologi pengiriman |
Untuk gambaran lebih lengkap tentang di mana manajemen proyek dan program berbeda dari kedua akuntabilitas Scrum, lihat perbandingan kami tentang manajemen program vs manajemen proyek.
Mana yang direkrut lebih dulu, atau mana yang sebaiknya Anda jalani
| Situasi Anda | Apa yang diprioritaskan |
|---|---|
| Backlog punya arah yang jelas, tetapi sprint terus gagal mencapai tujuannya, event berlarut, dan hambatan menumpuk tanpa penanganan | Scrum Master. Tim sudah punya arah; prosesnya yang perlu diperbaiki |
| Ritme sprint berjalan lancar, tetapi tidak ada yang bisa menjelaskan mengapa tim membangun apa yang dibangunnya | Product Owner. Prosesnya berjalan; "mengapa"-nya yang hilang |
| Anda membentuk Scrum Team pertama dari nol | Product Owner dulu, bahkan secara informal, supaya ada sesuatu yang layak di-sprint-kan. Scrum Master tanpa backlog untuk dilindungi belum punya apa pun untuk difasilitasi |
| Anda seorang developer yang lebih tertarik pada coaching, fasilitasi, dan gesekan organisasi daripada strategi backlog | Condongkan diri ke jalur karier Scrum Master |
| Anda seorang developer yang lebih tertarik pada percakapan dengan pelanggan, pertimbangan prioritas, dan memegang hasil daripada proses | Condongkan diri ke jalur karier Product Owner |
| Anda memilih di antara keduanya dengan mempertimbangkan arah karier jangka panjang | Product Owner cenderung lebih dekat ke pekerjaan strategi produk di kemudian hari, meskipun banyak Scrum Master pindah ke agile coaching atau kepemimpinan pengiriman |
Anti-pola umum
| Anti-pola | Wujudnya | Perbaikan |
|---|---|---|
| Scrum Master sebagai sekretaris | Mengirim undangan kalender, mencatat notulen, melapor status ke atas, tidak pernah membimbing atau menyingkirkan hambatan | Arahkan kembali ke fasilitasi dan penyingkiran hambatan; pelaporan status sama sekali bukan akuntabilitas dalam Guide |
| Scrum Master sebagai penulis laporan | Menghabiskan sebagian besar minggu menyusun grafik velocity dan burndown untuk manajemen alih-alih bekerja dengan tim | Serahkan pelaporan ke dashboard swalayan dari board; waktu Scrum Master milik tim |
| Product Owner sebagai perantara penulis tiket | Meneruskan keputusan manajer atau komite menjadi item backlog tanpa suara nyata dalam penentuan prioritas | Dorong organisasi memberi Product Owner wewenang sebenarnya; Product Owner yang tidak bisa menolak tidak bertanggung jawab atas apa pun |
| Product Owner yang tidak pernah tersedia | Backlog menjadi basi karena refinement dan pertanyaan klarifikasi tidak terjawab berhari-hari | Tetapkan jam konsultasi eksplisit atau slot refinement tetap yang dijaga Product Owner seperti seremoni lainnya |
| Scrum Master yang diam-diam memegang backlog | Turun tangan menyusun ulang atau menulis item backlog karena Product Owner lambat, mengaburkan kedua akuntabilitas sekaligus | Bimbing Product Owner alih-alih mengerjakan tugasnya; jika kesenjangannya struktural, eskalasikan, jangan diserap |
| Product Owner yang menjalankan Daily Scrum | Mengubah event pengelolaan diri tim menjadi rapat status yang melapor kepada Product Owner | Kehadiran Product Owner bersifat opsional menurut Guide; jika hadir, mereka mendengarkan, bukan menjalankannya |
Semua ini tidak mengendap menjadi keputusan bagan organisasi permanen yang diambil sekali lalu dilupakan. Tim berubah ukuran, produk berubah tahap, dan titik gesek dalam tabel tabrakan di atas muncul lagi setiap kali ada yang bergeser, entah itu pemangku kepentingan baru, backlog yang membesar, atau tim yang sudah melampaui peran gabungan yang semula dipilih karena terpaksa. Jalan tercepat kembali ke kejelasan saat itu terjadi bukan debat baru tentang jabatan. Melainkan kembali ke satu kalimat yang menjadi dasar setiap akuntabilitas: siapa yang bertanggung jawab atas nilai produk, dan siapa yang bertanggung jawab atas kemampuan tim menyampaikannya.
Pertanyaan yang Sering Diajukan tentang Scrum Master vs Product Owner
Apakah Scrum Master sama dengan Product Owner?
Tidak. Scrum Guide 2020 mendefinisikan keduanya sebagai dua akuntabilitas terpisah dalam Scrum Team yang sama. Product Owner bertanggung jawab memaksimalkan nilai produk dan mengelola backlog. Scrum Master bertanggung jawab atas efektivitas Scrum Team dan cara tim bekerja. Mereka setara dalam tim, bukan hierarki, dan tidak ada yang mengelola yang lain.
Bisakah Scrum Master menjadi Product Owner, atau sebaliknya?
Bisa, dan keduanya sering terjadi. Scrum Master yang ingin memegang hasil produk, bukan memfasilitasi proses tim, kerap pindah menjadi Product Owner setelah memiliki cukup pengetahuan domain dan pelanggan. Product Owner yang ingin menjauh dari tekanan pemangku kepentingan dan mendekat ke coaching tim kadang bergerak ke arah sebaliknya, secara sengaja.
Siapa yang memiliki wewenang lebih besar, Scrum Master atau Product Owner?
Mereka memiliki wewenang atas hal yang berbeda, bukan lebih atau kurang atas hal yang sama. Product Owner memiliki wewenang tunggal atas isi dan urutan backlog, menurut Scrum Guide. Scrum Master tidak punya wewenang atas apa yang dibangun tim, tetapi bertanggung jawab atas cara tim bekerja dan dapat menolak soal proses, batas waktu, dan hambatan. Tidak ada yang berada di atas yang lain.
Apakah tim kecil benar-benar membutuhkan keduanya secara terpisah?
Tidak selalu, setidaknya tidak sebagai dua orang berbeda. Tim yang sangat kecil kadang menggabungkan akuntabilitas itu pada satu orang, dan itu bisa berhasil untuk sementara. Namun kedua pekerjaan itu menarik ke arah berbeda (memperjuangkan nilai versus melindungi kapasitas tim), sehingga pengaturan itu cenderung tegang seiring bertambahnya tim, backlog, atau daftar pemangku kepentingan.
Apa perbedaan sebenarnya antara Scrum Master dan project manager?
Scrum Master tidak punya wewenang atas lingkup, anggaran, atau jadwal; Scrum Team mengelola pekerjaannya sendiri di dalam setiap Sprint. Project manager umumnya memegang jadwal, lingkup, dan pelaporan status, dan jabatan ini ada di hampir semua pendekatan pengiriman, bukan hanya Scrum. Peran Scrum Master hanya ada di dalam Scrum Team.
Apakah peran-peran ini ada di luar Scrum, misalnya di Kanban atau framework lain?
Jabatan "Scrum Master" dan "Product Owner" khusus untuk Scrum dan tidak ada secara formal di luarnya. Tim yang menjalankan Kanban atau framework lain tetap membutuhkan seseorang yang bertanggung jawab atas prioritas dan seseorang yang memperhatikan alur dan proses tim, hanya saja tanpa jabatan persis ini atau akuntabilitas persis yang ditetapkan Scrum Guide untuk mereka.
Apa pun sisi yang sedang Anda tata, entah Anda sedang merekrut, mengurai tim yang tercampur, atau memilih jalur karier, kalimat yang patut terus Anda ingat adalah kalimat yang memang ditulis Guide: satu orang bertanggung jawab atas nilai produk, yang lain atas efektivitas tim. Sisanya hanyalah detail.
On this page
- Dua akuntabilitas, bukan dua peran
- Scrum Master vs Product Owner sekilas
- Apa yang sebenarnya menjadi akuntabilitas Product Owner
- Apa yang sebenarnya menjadi akuntabilitas Scrum Master
- Di mana keduanya bertabrakan, dan cara tim yang sehat menyelesaikannya
- Event Scrum satu per satu: siapa melakukan apa
- Bisakah satu orang memegang keduanya?
- Scrum Master dan Product Owner vs Project Manager dan Product Manager
- Mana yang direkrut lebih dulu, atau mana yang sebaiknya Anda jalani
- Anti-pola umum