Definition of Done: Contoh dan Cara Menulisnya

Definition of done (DoD) adalah salah satu konsep yang terdengar jelas sampai tim Anda mengirimkan sesuatu yang rusak di produksi, melewatkan tinjauan, atau tidak pernah didokumentasikan. Saat itulah menjadi mendesak.

Apa itu definition of done (DoD)?

Definition of done adalah daftar periksa kriteria yang disepakati bersama yang harus dipenuhi item pekerjaan sebelum tim menganggapnya selesai. Bukan "hampir selesai." Bukan "selesai di mesin saya." Benar-benar selesai.

DoD berlaku untuk setiap Increment pekerjaan pada level yang sama, setiap cerita pengguna, setiap Sprint, setiap rilis. DoD tidak ditulis oleh satu orang lalu diserahkan untuk "disetujui." DoD dibuat bersama oleh tim, ditempatkan di tempat yang terlihat, dan diterapkan secara konsisten. Ketika pekerjaan memenuhi setiap item dalam daftar, pekerjaan selesai. Ketika tidak, belum selesai.

Fakta kunci: definition of done

• Tim dengan DoD yang terdokumentasi dengan jelas mengirimkan 28% lebih sedikit cacat daripada tim tanpa DoD, menurut penelitian yang diterbitkan dalam jurnal Empirical Software Engineering (2018).
• State of Agile Report 2023 (digital.ai) menemukan bahwa praktik yang tidak konsisten dan standar yang tidak jelas termasuk dalam lima alasan utama transformasi Agile gagal, DoD secara langsung mengatasi keduanya.
• Sebuah studi oleh Capers Jones menemukan bahwa memperbaiki cacat di produksi biayanya 10 hingga 100 kali lebih mahal daripada menangkapnya selama pengembangan; DoD yang mencakup persyaratan pengujian dan tinjauan adalah salah satu alat pencegahan cacat berbiaya terendah yang tersedia.

Definition of done vs. kriteria penerimaan

Dua istilah ini sering kali tertukar, dan kebingungan tersebut menimbulkan masalah nyata. Keduanya terkait tetapi mencakup area yang berbeda.

Kriteria penerimaan menjawab: apakah fitur ini melakukan apa yang seharusnya? DoD menjawab: apakah tim telah melakukan segalanya yang diperlukan untuk menyebut Increment ini siap dirilis?

Sebuah cerita dapat melewati semua kriteria penerimaannya dan tetap gagal DoD jika, misalnya, dokumentasi tidak diperbarui atau kode tidak ditinjau. Kedua gerbang harus terpenuhi.

Beberapa tim juga menggunakan definition of ready (DoR) di bagian depan, daftar periksa kondisi yang harus dipenuhi item pekerjaan sebelum tim menariknya ke dalam Sprint. DoD menutup lingkaran di bagian belakang. Bersama-sama, keduanya menciptakan batasan kualitas di seluruh siklus Sprint. Lihat backlog refinement untuk melihat bagaimana DoR cocok dalam persiapan Sprint.

Mengapa definition of done penting

Tanpa DoD, "selesai" berarti sesuatu yang berbeda bagi setiap orang di tim. Seorang pengembang menganggap fitur selesai ketika kode dikompilasi. Insinyur QA menganggapnya selesai ketika tes lulus. Tech lead menganggapnya selesai ketika sudah di-code-review. Product Owner menganggapnya selesai ketika sudah di-deploy. Tidak satu pun dari mereka yang salah. Namun jika mereka tidak pernah menyelaraskan diri pada satu standar, tim akan terus mengirimkan pekerjaan yang sebagian selesai dengan cara yang tidak diantisipasi siapa pun.

Inilah yang terjadi dalam praktiknya. Tim tanpa DoD:

• Mengirimkan kode yang berfungsi secara lokal tetapi gagal di staging karena pemeriksaan lingkungan bukan bagian dari daftar periksa mental siapa pun
• Menggabungkan pekerjaan yang "ditinjau" oleh orang yang menulisnya
• Mengumpulkan utang dokumentasi karena tidak ada yang mencatatnya sebagai persyaratan
• Menghabiskan separuh retrospektif Sprint mendiskusikan apa arti "selesai" sebenarnya untuk cerita yang baru saja mereka selesaikan

Tim dengan DoD:

• Memiliki standar bersama yang tidak dapat dinegosiasikan yang tidak bergantung pada interpretasi individual
• Menangkap celah selama Sprint, bukan setelah deployment
• Mengurangi pengerjaan ulang karena semua orang mengetahui kriteria keluar sebelum memulai
• Bergerak lebih cepat karena ada lebih sedikit kejutan saat tinjauan Sprint

DoD juga melindungi product backlog dari penyelesaian palsu. Ketika sebuah cerita ditandai selesai tanpa memenuhi semua kriteria, pekerjaan nyata, perbaikan, tinjauan, dokumentasi, terkubur di suatu tempat dalam Backlog dan muncul kembali kemudian sebagai pekerjaan yang tidak direncanakan.

Level-level done

Sebagian besar tim beroperasi dengan tiga level done. Setiap level memiliki daftar periksanya sendiri, dan daftar periksa level yang lebih tinggi biasanya mencakup semua yang ada di level di bawahnya.

Done tingkat cerita

Ini adalah daftar periksa yang diterapkan pada cerita pengguna atau tugas individual. Ini mencakup pekerjaan spesifik yang diperlukan untuk menyampaikan satu Increment:

• Kode ditulis dan ditinjau sendiri
• Unit test ditulis dan lulus
• Kode ditinjau oleh setidaknya satu anggota tim lain
• Kriteria penerimaan terpenuhi dan diverifikasi
• Feature branch digabungkan ke main (atau branch integrasi yang disepakati)

Done tingkat Sprint

Daftar periksa ini berlaku untuk seluruh Increment Sprint, jumlah semua cerita yang diselesaikan dalam Sprint. Sering kali menambahkan kriteria integrasi dan deployment:

• Semua item DoD tingkat cerita terpenuhi untuk setiap cerita yang disertakan
• Integration test lulus terhadap build penuh
• Di-deploy ke lingkungan staging
• Sprint Goal tercapai atau secara eksplisit dinilai
• Release notes atau change log diperbarui

Done tingkat rilis

Ini mencakup semua yang diperlukan sebelum Increment sampai ke pengguna produksi. Di sinilah kriteria kepatuhan, kinerja, dan persetujuan biasanya berada:

• End-to-end test lulus di lingkungan yang menyerupai produksi
• Benchmark kinerja terpenuhi (waktu muat, tingkat kesalahan, dll.)
• Security scan selesai tanpa temuan kritis
• Dokumentasi diperbarui dan dipublikasikan
• Persetujuan pemangku kepentingan diperoleh
• Rencana rollback didokumentasikan

Tim yang bekerja dalam perencanaan Sprint harus jelas tentang level done mana yang berlaku untuk output setiap Sprint. Tidak setiap Sprint berakhir dengan rilis produksi, tetapi tim harus tahu persis di mana batasnya sebelum mereka mulai.

Contoh definition of done

Berikut adalah daftar periksa DoD konkret untuk tiga jenis tim yang umum. Ini bukan template untuk disalin begitu saja, melainkan titik awal. DoD tim Anda harus mencerminkan standar, alat, dan alur kerja Anda yang sebenarnya.

Tim pengembangan perangkat lunak (tingkat cerita)

• Kode ditulis dan dikompilasi tanpa kesalahan
• Unit test ditulis untuk logika baru, dengan minimal 80% cakupan pada file yang diubah
• Kode ditinjau dan disetujui oleh setidaknya satu pengembang lain
• Semua automated test lulus dalam pipeline CI
• Tidak ada kesalahan linting baru yang diperkenalkan
• Fitur di-deploy ke lingkungan staging dan smoke-tested
• Kriteria penerimaan diverifikasi oleh pengembang atau QA
• API baru atau perubahan konfigurasi didokumentasikan di wiki tim
• Feature flag atau toggle tersedia jika pekerjaan belum siap untuk rollout penuh

Tim pemasaran dan konten (tingkat cerita)

• Konten ditulis sesuai jumlah kata dan panduan nada yang disepakati
• Ditinjau oleh penulis atau editor kedua untuk akurasi dan suara merek
• Daftar periksa SEO selesai (title tag, meta description, kata kunci target di H1)
• Semua tautan internal diverifikasi dan berfungsi
• Gambar dioptimalkan dan alt text ditambahkan
• Dijadwalkan atau diterbitkan di CMS sesuai kalender konten
• Tugas distribusi selesai (postingan media sosial dijadwalkan, inklusi newsletter dikonfirmasi)
• Pelacakan analitik dikonfirmasi (parameter UTM, tag acara sudah terpasang)

Tim desain (tingkat cerita)

• Desain sesuai dengan brief atau persyaratan cerita pengguna yang disetujui
• Ditinjau oleh lead designer dan pemangku kepentingan terkait
• Panduan aksesibilitas diperiksa (kontras warna, ukuran teks, aliran keyboard untuk elemen interaktif)
• Semua status didokumentasikan: default, hover, focus, error, kosong, loading
• Aset diekspor dalam format yang diperlukan dan diunggah ke perpustakaan desain bersama
• Catatan handoff ditulis untuk tim pengembangan
• Umpan balik terbuka dari tinjauan diselesaikan atau secara eksplisit ditangguhkan dengan alasan

Cara menulis definition of done

Langkah 1: Kumpulkan tim

DoD hanya berfungsi jika semua orang mempercayainya. Artinya membuatnya bersama: pengembang, desainer, QA, Product Owner, siapa saja yang melakukan pekerjaan. Workshop 60 menit biasanya cukup untuk mendapatkan versi pertama. Jangan biarkan Scrum Master atau pemimpin tim menulisnya sendiri lalu mempresentasikannya untuk "persetujuan." Ko-kreasi adalah intinya.

Langkah 2: Daftarkan apa yang sebenarnya dibutuhkan untuk penyelesaian

Mulailah dengan bertanya kepada tim: "Pikirkan pekerjaan terakhir yang Anda kirimkan yang kembali dengan masalah. Langkah apa yang dilewati?" Kerjakan mundur dari kegagalan untuk menemukan item daftar periksa yang penting. Kemudian kerjakan ke depan: seperti apa yang baik ketika kita mengirimkan sesuatu? Apa yang akan membuat kita malu jika kita melupakannya?

Kelompokkan item ke dalam kategori: kualitas kode, pengujian, dokumentasi, deployment, tinjauan. Ini membuat DoD lebih mudah dipindai selama Sprint.

Langkah 3: Jaga agar setiap item dapat diverifikasi

Setiap item DoD harus dapat diverifikasi, baik sudah selesai maupun belum. "Kualitas kode bagus" bukan item DoD. "Kode ditinjau dan disetujui oleh setidaknya satu anggota tim selain penulisnya" adalah item DoD. Tesnya: bisakah Anda menunjukkan bukti bahwa item ini diselesaikan? Jika ya, item tersebut masuk DoD. Jika memerlukan penilaian, ubah menjadi panduan atau pecah menjadi kriteria yang lebih spesifik.

Langkah 4: Sepakati dan tempatkan di tempat yang terlihat

Setelah tim memiliki draf, dapatkan kesepakatan yang eksplisit. Bukan "tidak ada keberatan" melainkan dukungan nyata. Tempatkan DoD di suatu tempat yang dilihat seluruh tim setiap hari, papan Sprint, wiki tim, deskripsi saluran di Slack. Jangan biarkan menjadi dokumen yang terkubur di folder yang tidak pernah dibuka siapa pun. Jika tim tidak dapat melihatnya, DoD tidak akan digunakan.

Langkah 5: Tinjau dan kembangkan

DoD bukan sesuatu yang permanen. DoD harus ditinjau dalam retrospektif Sprint setiap kali tim mengirimkan sesuatu yang mengungkapkan celah. Ketika tim menambahkan alat baru (misalnya, automated security scanner), tambahkan ke DoD. Ketika item daftar periksa menjadi begitu otomatis sehingga tidak ada yang melewatinya, pertimbangkan apakah item tersebut masih perlu ditulis atau sudah menjadi kebiasaan tim.

DoD yang tidak pernah berubah entah sempurna (tidak mungkin) atau diabaikan (lebih mungkin).

Kesalahan umum

Membuatnya terlalu panjang. DoD dengan 30 item tidak akan digunakan. Targetkan 8 hingga 12 item yang mencakup celah kualitas nyata Anda, bukan ideal yang komprehensif. Jika Anda tidak dapat mengingat DoD dari memori setelah seminggu, terlalu panjang.

Menulisnya di tingkat organisasi alih-alih tingkat tim. DoD yang diturunkan dari pimpinan mencakup kebijakan, bukan praktik. Setiap tim membutuhkan DoD yang mencerminkan alur kerja, alat, dan standar mereka yang sebenarnya.

Memperlakukannya sebagai aspirasional. Jika tim tidak dapat secara realistis memenuhi setiap item DoD dalam Sprint normal, DoD tersebut bersifat aspirasional, bukan operasional. Potong kembali menjadi apa yang sebenarnya dapat dikomitmen tim, lalu naikkan standarnya secara bertahap seiring kapasitas dan alat membaik.

Melewatinya saat tekanan tinggi. "Kita akan melewati dokumentasi Sprint ini karena waktu kita terbatas" adalah saat DoD berhenti berarti apapun. Pengecualian sebagian menumpuk menjadi pengecualian yang konsisten. Jika DoD dapat ditangguhkan di bawah tekanan, itu tidak pernah menjadi standar nyata.

Melupakan persyaratan non-fungsional. Perilaku fungsional tercakup oleh kriteria penerimaan. DoD adalah tempat standar kinerja, keamanan, aksesibilitas, dan dokumentasi berada. Tim yang tidak memasukkan hal-hal ini ke dalam DoD mengirimkan fitur yang berfungsi tetapi menurunkan sistem dari waktu ke waktu.

Pertanyaan yang sering diajukan

Siapa yang memiliki definition of done?

Tim memilikinya secara kolektif. Product Owner dapat mempengaruhinya (mereka peduli tentang kesiapan rilis), dan Scrum Master dapat memfasilitasi pembuatan dan tinjauan DoD. Namun dalam Scrum, para Developer adalah yang berkomitmen untuk memenuhi DoD untuk setiap Increment. Tidak ada yang dapat mengubahnya secara sepihak di tengah Sprint.

Apa perbedaan antara definition of done dan daftar periksa?

DoD adalah jenis daftar periksa, tetapi dengan tujuan dan kontrak tertentu di baliknya. Daftar periksa adalah alat. DoD adalah kesepakatan bahwa setiap Increment harus melewati batas ini sebelum tim menyebutnya selesai. Perbedaannya penting karena mengimplikasikan kepemilikan bersama dan konsekuensi: pekerjaan yang tidak memenuhi DoD tidak dihitung dalam Sprint Goal.

Apakah setiap tim membutuhkan definition of done?

Ya, jika tim mengirimkan pekerjaan yang bergantung pada orang lain. DoD adalah mekanisme yang membuat "selesai" berarti hal yang sama bagi semua orang. Tim tanpa DoD mengembangkan standar implisit (yang tidak dibagikan atau diterapkan) atau berdebat tentang selesai-tidaknya pekerjaan pada saat-saat terburuk, biasanya di akhir Sprint.

Bisakah definition of done berbeda untuk jenis pekerjaan yang berbeda?

Ya, dengan hati-hati. Banyak tim memiliki DoD tingkat cerita dan DoD tingkat Sprint (seperti yang dijelaskan di bagian level di atas). Beberapa tim memiliki kriteria yang sedikit berbeda untuk perbaikan bug vs. fitur baru. Namun berhati-hatilah terhadap fragmentasi. Semakin banyak pengecualian dan kasus khusus yang dimiliki DoD, semakin besar beban kognitif yang diciptakannya dan semakin tidak andal penerapannya.

Bagaimana definition of done berhubungan dengan story points?

Story points memperkirakan upaya relatif. DoD mendefinisikan standar kualitas. Keduanya terkait karena DoD harus diperhitungkan dalam estimasi. Jika memenuhi DoD untuk sebuah cerita membutuhkan 3 jam ekstra, waktu tersebut harus tercermin dalam estimasi story point, bukan diperlakukan sebagai overhead yang dilewati ketika tim dalam tekanan. Ketika tim meremehkan cerita karena tidak memperhitungkan persyaratan DoD, mereka berakhir dalam tekanan yang persis mengarah pada jalan pintas DoD.

---

Definition of done yang dibuat dengan baik tidak memperlambat tim. Justru menghilangkan ambiguitas yang memperlambat tim. Ketika semua orang tahu persis arti "selesai" sebelum mereka mulai, ada lebih sedikit kejutan, lebih sedikit putaran pengerjaan ulang, dan lebih sedikit perdebatan saat tinjauan Sprint. Mulailah dengan sesuatu yang sederhana, terapkan secara konsisten, dan biarkan berkembang seiring tim.

Bacaan terkait

• Product backlog
• Backlog refinement
• User stories
• Story points
• Retrospektif Sprint
• Perencanaan Sprint
• Apa itu Scrum?