Metode MoSCoW: Prioritaskan Persyaratan dengan Cara yang Tepat

Metode MoSCoW adalah salah satu kerangka prioritisasi paling praktis yang tersedia bagi tim proyek, dan hanya membutuhkan sekitar tiga puluh menit untuk dipelajari namun butuh kedisiplinan seumur hidup untuk diterapkan dengan baik. Sebagian besar tim tidak gagal karena memilih alat yang salah. Mereka gagal karena mengatakan ya untuk segalanya dan akhirnya tidak menghasilkan sesuatu yang berguna tepat waktu.

Apa itu metode MoSCoW?

Metode MoSCoW adalah teknik prioritisasi terstruktur yang digunakan dalam manajemen proyek, pengembangan produk, dan analisis bisnis untuk memilah persyaratan, fitur, atau tugas ke dalam empat kategori berdasarkan kepentingan dan urgensinya. Setiap huruf dalam akronim memetakan ke satu kategori:

• Must have: Persyaratan yang tidak dapat dinegosiasikan. Proyek gagal tanpa ini.
• Should have: Penting tetapi tidak kritis. Item-item ini menambahkan nilai signifikan dan harus disertakan jika memungkinkan.
• Could have: Fitur yang bagus untuk dimiliki. Sertakan hanya jika waktu dan anggaran memungkinkan tanpa mengancam Must-have.
• Won't have (kali ini): Secara eksplisit di luar ruang lingkup untuk penyerahan ini. Frasa "kali ini" penting, karena item-item ini mungkin muncul dalam iterasi mendatang.

Kerangka kerja ini dikembangkan oleh Dai Clegg di Oracle UK pada tahun 1994 dan kemudian diformalisasikan dalam Dynamic Systems Development Method (DSDM). Huruf kecil dalam MoSCoW (huruf "o" dan "W") adalah pengisi agar akronim dapat diucapkan. Empat huruf bermakna adalah M, S, C, dan W.

Fakta Utama

• Standish Group CHAOS Report menemukan bahwa 45% fitur dalam produk perangkat lunak tidak pernah digunakan, dan 19% lebih jarang digunakan, artinya hampir dua pertiga dari apa yang dibangun tim memberikan nilai minimal (Standish Group CHAOS Report, 2020).
• Proyek yang menggunakan prioritisasi persyaratan terstruktur dua kali lebih mungkin dikirimkan tepat waktu dan sesuai anggaran dibandingkan dengan yang tanpa prioritisasi formal (PMI Pulse of the Profession, 2021).
• Tim yang dengan jelas mendefinisikan item di luar ruang lingkup di awal proyek mengurangi perubahan ruang lingkup di tengah proyek hingga 30% (penelitian praktisi Konsorsium DSDM, 2019).

Empat kategori MoSCoW

Pembagian 60/20/15/5 adalah panduan kasar, bukan aturan. Kendala kritisnya adalah Must-have tidak boleh melebihi kapasitas pengiriman tim yang telah dikonfirmasi. Jika melebihi, kategorisasi yang salah, bukan kapasitasnya.

MoSCoW vs metode prioritisasi lainnya

MoSCoW biasanya merupakan kerangka kerja tercepat untuk diterapkan dalam lokakarya pemangku kepentingan karena menggunakan kategori bahasa sederhana alih-alih skor atau kurva. Ini menjadikannya sangat berguna ketika Anda membutuhkan dukungan dari pemangku kepentingan non-teknis sebelum perencanaan Sprint atau kickoff pengiriman.

Manfaat prioritisasi MoSCoW

Menciptakan bahasa bersama. Ketika seorang manajer produk mengatakan "itu adalah Should," semua orang di tim tahu artinya. Tidak ada yang membuang waktu bertanya apakah sebuah fitur "penting" (segalanya penting bagi siapa pun yang memintanya).

Memaksa pilihan yang eksplisit. Kategori Won't-have adalah bagian paling powerful dari kerangka kerja ini. Menuliskan apa yang tidak Anda bangun lebih sulit dari yang terdengar, dan ini mencegah ruang lingkup berkembang diam-diam setelah kick-off.

Menyelaraskan pemangku kepentingan sebelum pekerjaan dimulai. Menjalankan lokakarya MoSCoW dengan matriks RACI pemangku kepentingan secara penuh memunculkan ketidaksepakatan tentang prioritas lebih awal, saat masih murah untuk diselesaikan. Konflik prioritas di tahap akhir sangat mahal.

Cocok secara alami dengan pengiriman agile. Kerangka kerja ini berpadu dengan baik dengan metodologi agile karena menetapkan ruang lingkup setiap iterasi alih-alih seluruh proyek. Tim menjalankan ulang MoSCoW di awal setiap siklus rilis alih-alih mengunci persyaratan sekali saja.

Melindungi Must-have. Dengan memberi item prioritas tertinggi bucket terlindungi mereka sendiri, kerangka kerja mempersulit secara politis untuk mengatakan tidak pada tambahan. "Itu akan menggeser sesuatu dari Must-have" adalah argumen yang lebih sulit ditolak daripada "kami tidak punya waktu saja."

Kesalahan umum

1. Terlalu banyak Must-have. Ini adalah mode kegagalan paling umum. Ketika segalanya kritis, tidak ada yang kritis. Daftar Must-have yang sehat harus muat dalam kapasitas pengiriman yang dikonfirmasi dengan margin untuk hal tak terduga. Jika Must-have Anda menghabiskan 90 persen kapasitas, Anda tidak memiliki penyangga untuk masalah teknis, dan Anda telah membuat Should-have tidak relevan.

2. Tidak ada daftar Won't-have. Tim yang melewati bucket ini membiarkan ruang lingkup ambigu. Pemangku kepentingan mengisi ambiguitas itu dengan asumsi. Tentukan daftar Won't-have secara tertulis dan bagikan kepada semua orang yang menyetujui Must-have.

3. Memperlakukan kategori sebagai permanen. MoSCoW adalah penilaian pada waktu tertentu untuk jendela pengiriman tertentu. Could-have pada rilis satu mungkin menjadi Must-have pada rilis dua. Tinjau kembali kategorisasi di awal setiap iterasi.

4. Menggunakan MoSCoW tanpa kendala waktu. Kerangka kerja hanya berfungsi ketika Anda memprioritaskan terhadap jadwal atau anggaran yang tetap. Tanpa kendala, segalanya tetap Must-have karena tidak ada fungsi pemaksa untuk memilih.

5. Menjalankan lokakarya tanpa pemangku kepentingan yang tepat. Kategorisasi yang dilakukan oleh seorang analis atau manajer proyek tunggal tanpa masukan pemangku kepentingan menghasilkan daftar yang tidak dimiliki oleh siapa pun. Sesi ini membutuhkan orang-orang yang akan hidup dengan pilihan tersebut.

6. Membingungkan Should-have dengan Could-have. Should-have adalah sesuatu yang bisnis secara aktif kehilangan jika tidak ada. Could-have adalah peningkatan yang bagus. Perbedaannya penting ketika Anda memutuskan apa yang harus dipangkas di bawah tekanan.

Cara menggunakan metode MoSCoW

Langkah 1: Kumpulkan persyaratan

Kumpulkan semua persyaratan, fitur, cerita pengguna, atau tugas yang menjadi kandidat untuk pengiriman. Pada tahap ini, jangan menyaring apa pun. Anda ingin daftar lengkap sebelum mulai menyortirnya. Gunakan pernyataan ruang lingkup proyek sebagai dokumen batas untuk mengkonfirmasi apa yang ada dan tidak ada dalam proyek secara keseluruhan.

Matriks analisis pemangku kepentingan membantu mengidentifikasi masukan siapa yang Anda butuhkan selama lokakarya prioritisasi. Pemangku kepentingan yang berbeda memiliki persyaratan yang berbeda, dan otoritas relatif mereka membentuk cara konflik diselesaikan.

Langkah 2: Sepakati definisi kategori

Sebelum tim mulai mengkategorisasi, habiskan lima menit untuk mengkonfirmasi apa yang dimaksud setiap bucket dalam konteks spesifik ini. Untuk beberapa proyek, "Must have" berarti diwajibkan secara hukum. Untuk yang lain, berarti secara teknis diperlukan agar MVP berfungsi. Menyelaraskan definisi sebelum mengkategorisasi mencegah sesi terhenti pada setiap item kedua.

Langkah 3: Kategorisasi secara kolaboratif

Dengan semua persyaratan terlihat (papan tulis, catatan tempel, atau spreadsheet bersama), tim menetapkan setiap item ke sebuah bucket. Kerjakan daftar secara sistematis. Untuk setiap persyaratan, tanyakan:

• Akankah produk tidak dapat digunakan atau tidak patuh tanpa ini? Jika ya, ini Must.
• Apakah kami akan mengirimkannya dengan penyesalan yang signifikan jika tidak ada? Jika ya, ini Should.
• Apakah kami akan menambahkannya jika kami punya waktu luang? Could.
• Apakah ini di luar ruang lingkup untuk pengiriman ini? Won't (kali ini).

Ketidaksepakatan pada tahap ini adalah sehat. Mereka memunculkan ekspektasi yang tidak selaras lebih awal. Selesaikan sekarang, bukan selama standup harian Scrum tiga minggu ke depan.

Langkah 4: Periksa kewarasan anggaran Must-have

Setelah kategorisasi awal selesai, jumlahkan perkiraan usaha untuk semua item Must-have. Bandingkan total itu dengan kapasitas pengiriman Anda yang dikonfirmasi (jam atau Story Point yang tersedia dikurangi buffer kontinjensi 20 persen). Jika Must-have melebihi kapasitas, sesuatu perlu dipindahkan. Turunkan Must-have yang paling lemah ke Should-have sampai angkanya sesuai.

Langkah ini adalah di mana MoSCoW membayar dirinya sendiri. Tanpanya, tim menemukan kelebihan komitmen pada dua pertiga proyek, ketika sudah terlambat untuk menyesuaikan dengan anggun.

Langkah 5: Tinjau dan revisi setiap iterasi

Di awal setiap Sprint atau siklus rilis, tinjau ulang daftar. Item yang selesai dihapus. Penemuan baru, kebutuhan bisnis yang berubah, atau kendala teknis dapat menggeser item antarkategori. Daftar Won't-have dari iterasi sebelumnya adalah sumber kandidat terbaik untuk dipromosikan ke Could-have atau Should-have pada iterasi berikutnya.

Siklus tinjauan ini yang menjaga MoSCoW selaras dengan realitas alih-alih rencana awal. Piagam proyek menetapkan batas strategis; MoSCoW menjaga pelaksanaan taktis dalam batas tersebut.

Contoh MoSCoW

Tabel di bawah menunjukkan daftar fitur untuk MVP portal proyek yang menghadap pelanggan, diurutkan berdasarkan kategori MoSCoW.

Must-have mendefinisikan produk yang berfungsi. Won't-have mendefinisikan batas negosiasi dengan pemangku kepentingan yang menginginkan segalanya pada hari pertama.

Praktik terbaik

Jalankan MoSCoW sebagai lokakarya, bukan latihan solo. Diskusi selama kategorisasi adalah di mana penyelarasan terjadi. Spreadsheet yang diisi oleh satu orang dan dikirim melalui email tidak menghasilkan kepemilikan bersama yang sama.

Tulis Must-have sebagai kriteria penerimaan, bukan nama fitur. "Login yang aman" itu ambigu. "Pengguna dapat masuk dengan email dan kata sandi, sesi berakhir setelah 30 menit tidak aktif, dan percobaan login yang gagal dibatasi kecepatan" dapat diuji. Kriteria yang jelas memudahkan untuk mengkonfirmasi kapan Must-have benar-benar selesai.

Jaga daftar Won't-have tetap terlihat sepanjang proyek. Cetak, tempelkan, masukkan ke header papan Scrum vs Kanban, atau posting di saluran tim. Item di luar ruang lingkup memiliki kebiasaan masuk kembali ke ruang lingkup secara diam-diam saat tidak ada yang memperhatikan.

Gunakan MoSCoW bersama proses estimasi Anda, bukan sebagai penggantinya. Prioritisasi tanpa perkiraan kapasitas adalah angan-angan. Jalankan pemeriksaan kewarasan di Langkah 4 setiap kali Anda memperbarui daftar.

Jujurlah tentang apa yang dimaksud "Won't have kali ini." Ini bukan penolakan yang sopan. Ini adalah penundaan yang terjadwal. Jika Anda tahu sebuah item tidak akan pernah dibangun, katakan dengan jelas alih-alih menaruhnya di Won't-have tanpa batas waktu. Tim dan pemangku kepentingan berhak atas kejelasan.

Pertanyaan yang sering diajukan

Apa yang dimaksud "o" dalam MoSCoW?

Tidak ada artinya. Huruf kecil "o" adalah huruf pengisi yang ditambahkan agar akronim dapat diucapkan. Empat huruf bermakna adalah M (Must have), S (Should have), C (Could have), dan W (Won't have). Dai Clegg menciptakan istilah tersebut di Oracle pada tahun 1994, dan kapitalisasi yang tidak biasa itu disengaja, untuk menandakan bahwa hanya empat dari enam huruf yang membawa makna.

Berapa persentase persyaratan yang harus menjadi Must-have?

Tidak ada aturan universal, tetapi sebagian besar praktisi merekomendasikan agar persyaratan Must-have tidak menghabiskan lebih dari 60 hingga 70 persen kapasitas pengiriman yang tersedia. Ini menyisakan ruang untuk Should-have dan buffer kontinjensi. Jika Must-have Anda secara konsisten mencapai 80 hingga 100 persen kapasitas, Anda tidak memprioritaskan, Anda hanya mendaftar semua yang Anda rencanakan untuk dibangun.

Bisakah persyaratan berpindah antarkategori?

Ya, dan memang harus. MoSCoW adalah alat yang hidup. Should-have dalam satu Sprint mungkin menjadi Must-have pada Sprint berikutnya jika perubahan regulasi atau komitmen pelanggan mengubah kepentingannya. Tinjau dan perbarui kategori di awal setiap iterasi alih-alih memperlakukan kategorisasi awal sebagai final.

Bagaimana MoSCoW cocok dengan pengiriman agile?

MoSCoW cocok secara alami dengan agile karena kedua pendekatan merangkul iterasi dan pilihan. Dalam konteks agile, MoSCoW menetapkan ruang lingkup setiap Sprint atau rilis alih-alih seluruh Roadmap produk. Product Owner biasanya menjalankan lokakarya kategorisasi sebelum perencanaan Sprint. Backlog Sprint kemudian diambil dari Must-have terlebih dahulu, Should-have jika kapasitas memungkinkan, dan Could-have hanya jika ada Slack yang terkonfirmasi.

Siapa yang harus memfasilitasi sesi MoSCoW?

Manajer proyek atau analis bisnis biasanya memfasilitasi, tetapi sesi harus menyertakan semua pemangku kepentingan dengan otoritas pengambilan keputusan atas persyaratan. Itu biasanya berarti Product Owner atau sponsor, pimpinan teknis utama, dan fungsi bisnis mana pun dengan kepentingan signifikan dalam pengiriman. Tugas fasilitator adalah menjaga percakapan terus bergerak dan memastikan ketidaksepakatan diselesaikan (bukan ditunda) sebelum sesi berakhir.

---

Prioritisasi bukan keterampilan teknis. Ini adalah disiplin pengambilan keputusan, dan MoSCoW memberi disiplin itu sebuah struktur yang dapat digunakan oleh sebagian besar tim tanpa sertifikasi atau spreadsheet penilaian. Mulailah dengan daftar persyaratan yang lengkap, jalankan lokakarya dengan orang yang tepat, lindungi Must-have dari kelebihan komitmen, dan tuliskan apa yang tidak Anda bangun. Sisanya mengikuti.

Bacaan terkait

• Apa itu Metodologi Agile?
• Perencanaan Sprint: Cara Menjalankan Rapat Perencanaan Sprint yang Efektif
• Apa itu Scrum?
• Scrum vs Kanban
• Pernyataan Ruang Lingkup Proyek
• Matriks RACI
• Piagam Proyek
• Matriks Analisis Pemangku Kepentingan