Belajar Scrum Master - Definition of Done & Quality
Memahami Definition of Done secara mendalam: bagaimana menetapkan DoD yang efektif, menjaga kualitas increment, dan menghubungkannya dengan engineering practices seperti automated testing, code review, dan continuous integration
#Pendahuluan
Setelah di episode 11 kita memahami Removing Impediments, pada episode ini kita masuk ke Definition of Done (DoD) — kriteria kualitas yang harus dipenuhi agar item dianggap selesai. DoD bukan sekadar checklist teknis, melainkan komitmen tim terhadap kualitas.
Mengapa DoD kritis? Karena tanpa DoD yang jelas, "selesai" memiliki makna berbeda bagi setiap orang. Developer mungkin menganggap kode sudah selesai, QA menganggap belum, dan PO menganggap hanya jika user bisa pakai. DoD menciptakan standar kualitas yang konsisten dan menghilangkan ambiguitas.
#Komponen DoD
#DoD Umum
| Kriteria | Arti |
|---|---|
| Code reviewed | Semua kode sudah di-review oleh minimal satu orang |
| Tests passing | Unit test, integration test lulus |
| Documentation updated | Dokumentasi terkait sudah di-update |
| PO accepted | PO menyetujui hasilnya |
| Deployable | Bisa di-deploy ke production |
#DoD Tambahan (Opsional)
| Kriteria | Kapan Ditambahkan |
|---|---|
| Security scan passed | Aplikasi memproses data sensitif |
| Performance benchmark met | Aplikasi membutuhkan performa tinggi |
| Accessibility checked | Aplikasi publik |
| Monitoring configured | Fitur baru membutuhkan observability |
#DoD vs Acceptance Criteria
| Aspek | DoD | Acceptance Criteria |
|---|---|---|
| Scope | Semua item | Per item |
| Standar | Konsisten | Bervariasi per item |
| Tujuan | Kualitas umum | Fitur spesifik |
| Siapa yang membuat | Tim (collaborative) | PO + Developers |
Tip
DoD harus dibuat oleh TIM, bukan oleh SM atau manajemen. Ketika tim sendiri yang menetapkan standar, mereka akan lebih berkomitmen untuk memenuhinya. Mulai dari DoD sederhana dan tingkatkan secara bertahap.
#Quality Practices dalam Scrum
#Automated Testing
| Jenis Test | Tujuan | Proporsi Ideal |
|---|---|---|
| Unit test | Test fungsi individual | 70% |
| Integration test | Test interaksi antar komponen | 20% |
| E2E test | Test alur pengguna utama | 10% |
#Code Review
- Minimal satu reviewer sebelum merge.
- Fokus: correctness, readability, maintainability.
- Bukan: style (gunakan linter/formatter).
#Continuous Integration
- Build otomatis setiap push.
- Test otomatis berjalan di CI.
- Deploy otomatis ke staging jika semua lulus.
#Praktik: DoD Setup
[ ] DoD dibuat oleh tim (collaborative)
[ ] DoD termasuk minimum: code review, tests passing, deployable
[ ] DoD ditempatkan di tempat yang terlihat semua orang
[ ] DoD di-review dan di-update setiap quarter
[ ] Semua anggota tim memahami dan berkomitmen pada DoD
[ ] Increment yang tidak memenuhi DoD tidak dianggap selesai#Penutup
Inti yang harus dibawa pulang:
- DoD adalah standar kualitas konsisten yang dibuat oleh tim.
- DoD berbeda dari acceptance criteria: umum vs spesifik per item.
- Quality practices: automated testing, code review, CI.
- DoD harus di-review dan di-update secara berkala.
Di episode 13 selanjutnya kita akan membahas Estimation & Velocity — teknik estimasi, velocity tracking, dan forecasting: bagaimana memperkirakan effort dan menggunakan data historis untuk perencanaan yang lebih baik. Pastikan DoD kalian sudah solid, karena estimasi yang akurat membutuhkan data dari increment yang benar-benar "done"!