Grooming tugas dalam pengembangan mobile: esensi, tujuan dan proses pelaksanaan

Apa itu grooming tugas?

Backlog Grooming (refinement) — proses mempersiapkan tugas Product Backlog untuk sprint mendatang. Pertemuan di mana Product Owner dan tim pengembang meninjau tugas: memperjelas persyaratan, menambahkan Acceptance Criteria, mengevaluasi kompleksitas, mengidentifikasi dependensi dan risiko. Dalam Scrum Guide tidak ada acara wajib „grooming" — ini adalah praktik tambahan yang diperkenalkan tim Scrum untuk mengurangi ketidakpastian pada Sprint Planning. Frekuensi yang direkomendasikan — 1 kali per sprint, tidak lebih dari 60 menit.

Istilah „merapikan" (grooming) mencerminkan esensi: tim „merapikan" backlog, menghapus tugas usang, memperjelas yang tidak jelas dan memecah yang terlalu besar. Dalam pengembangan mobile, grooming sangat penting karena spesifikasi platform: tugas untuk Android mungkin berbeda dari versi iOS dalam kompleksitas, perlu mempertimbangkan targetSdk, compileSdk, kompatibilitas dengan level API. Tanpa grooming, Sprint Planning berubah menjadi kekacauan: tim melihat tugas untuk pertama kali dan tidak dapat mengevaluasinya, yang menyebabkan ketidakpastian dan keterlambatan.

Hasil grooming — beberapa tugas siap untuk Sprint Planning: mereka memiliki deskripsi, Acceptance Criteria, evaluasi dan sesuai dengan Definition of Ready. Product Owner harus melakukan grooming tugas dalam urutan prioritas: yang terdekat dengan sprint saat ini — yang paling detail. Tugas untuk 3-4 sprint ke depan — hanya di level epik. Teknik Progressive Refinement: semakin dekat tugas dengan sprint, semakin detail deskripsinya. Untuk tugas di sprint saat ini — full refinement (AC, desain, spesifikasi API). Untuk tugas 2 sprint mendatang — story-level (user story tanpa detail implementasi). Untuk tugas 3+ sprint mendatang — epic-level (hanya nama dan nilai bisnis).

Definition of Ready: kapan tugas siap untuk sprint

Definition of Ready (DoR) — daftar periksa kriteria yang harus dipenuhi tugas sebelum dimasukkan ke dalam Sprint Backlog. DoR adalah kontrak antara Product Owner dan tim: PO menjamin bahwa semua informasi untuk pengembangan tersedia, tim menjamin bahwa mereka dapat mengevaluasi dan melaksanakan tugas. DoR tidak universal — setiap tim menentukan kriterianya sendiri. Tanpa DoR, tugas dapat masuk ke sprint dengan persyaratan yang tidak jelas, yang menyebabkan pengerjaan ulang dan keterlambatan.

DoR tipikal untuk pengembangan mobile: 1) Acceptance Criteria dijelaskan (kriteria penerimaan dalam format Given-When-Then). 2) Mockup desain siap di Figma (untuk tugas UI) dengan semua status: default, loading, error, empty state. 3) Spesifikasi API disetujui (OpenAPI/Swagger, contoh permintaan dan respons). 4) Evaluasi dalam story point ada. 5) Dependensi dari tugas lain teridentifikasi. 6) Tugas tidak bergantung pada komponen eksternal yang belum siap. 7) Spesifikasi mobile: versi OS target, kebutuhan feature flag, dukungan untuk level API lama ditentukan.

Teknik evaluasi tugas

Planning Poker — teknik evaluasi paling populer pada grooming. Setiap pengembang menerima satu set kartu dengan angka Fibonacci (1, 2, 3, 5, 8, 13, 21). PO menunjukkan tugas dan menjelaskannya. Setelah diskusi, semua orang secara bersamaan menunjukkan kartu. Jika evaluasi sangat berbeda (misalnya, 3 dan 13) — pengembang menjelaskan evaluasi mereka, kemudian memberikan suara lagi. Iterasi diulang sampai konsensus. Tujuan Planning Poker bukanlah evaluasi yang tepat, melainkan mengidentifikasi perbedaan dalam pemahaman tugas.

T-Shirt Sizing — teknik yang disederhanakan untuk evaluasi cepat: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Cocok untuk penyortiran awal backlog ketika ada banyak tugas dan perlu dengan cepat memperkirakan urutan besarnya. Setelah T-Shirt Sizing, evaluasi yang lebih akurat dilakukan melalui Planning Poker untuk tugas sprint berikutnya. Affinity Estimation — penyortiran kelompok tugas berdasarkan kompleksitas relatif tanpa angka; tugas diletakkan di meja dari yang paling sederhana hingga yang paling kompleks, kemudian dikelompokkan ke dalam cluster, setiap cluster mendapat evaluasi.

Dalam pengembangan mobile, evaluasi harus mempertimbangkan kompleksitas platform. Tugas Android mungkin dievaluasi pada 5 SP, dan tugas yang sama untuk iOS — pada 3 SP (atau sebaliknya). Ini normal: platform yang berbeda memiliki kompleksitas implementasi yang berbeda. Saran: evaluasi setiap platform secara terpisah jika tim bersifat cross-platform. Gunakan skala relatif: tugas dasar (misalnya, layar dengan teks dan tombol) = 1 SP. Semua yang lain — relatif terhadapnya. Menurut Scrum.org (2025), setelah 3-4 sprint, akurasi evaluasi tim mencapai ±20% dari kompleksitas aktual.

Dekomposisi: cara memecah tugas besar

Tugas lebih besar dari 8 SP harus didekomposisi menjadi lebih kecil. Tugas besar tidak dapat diselesaikan dalam satu sprint, sulit dievaluasi dan tidak memberikan rasa kemajuan. Teknik dekomposisi: bagi tugas berdasarkan lapisan horizontal (UI → ViewModel → Repository → Network/DB) atau irisan vertikal (feature: satu layar secara utuh). Dekomposisi horizontal lebih cocok untuk pengembangan mobile: Sub-task 1 — tata letak UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Pengujian unit.

Dekomposisi vertikal — memotong user story menjadi cerita yang lebih kecil dengan nilai independen. Contoh: Epic „Keranjang Belanja" → Story 1 „Menambahkan produk ke keranjang", Story 2 „Menampilkan keranjang", Story 3 „Menghapus produk dari keranjang", Story 4 „Checkout pesanan". Setiap Story memiliki nilai bisnisnya sendiri dan dapat dirilis secara independen. SPoK (Story Points on Kano): urutkan Stories berdasarkan nilai bisnis (Must-have, Should-have, Could-have) dan implementasikan sesuai urutan nilai.

Daftar periksa dekomposisi pada grooming: 1) Tugas lebih besar dari 8 SP? → Dekomposisi. 2) Ada Acceptance Criteria? → Jika tidak — tambahkan. 3) Bergantung pada tugas lain? → Identifikasi dan catat dependensi. 4) Mengandung ketidakpastian? → Tambahkan Spike (penelitian) sebelum tugas utama. 5) Perlu desain? → Periksa kesiapan mockup. Aturan INVEST: Independent (independen dari yang lain), Negotiable (dapat dinegosiasikan), Valuable (berharga untuk bisnis), Estimable (dapat dievaluasi), Small (kecil), Testable (dapat diuji). Jika tugas tidak memenuhi INVEST — tugas tersebut belum siap untuk sprint.

Proses grooming: langkah demi langkah

Langkah 1: Pemanasan (5 menit). Scrum Master mengingatkan tujuan grooming dan DoR. Tim melihat papan, PO menunjukkan tugas mana yang akan dibahas. Langkah 2: Tinjauan tugas (30 menit). PO secara berurutan menyajikan tugas dari akhir sprint saat ini dan awal sprint berikutnya. Untuk setiap tugas: nama, deskripsi, Acceptance Criteria (jika ada), tautan ke desain, spesifikasi API. Tim mengajukan pertanyaan klarifikasi: „Apakah ada mockup untuk status kosong?", „Metode HTTP apa?", „Apa iOS minimum deployment target?".

Langkah 3: Evaluasi (15 menit). Tim mengevaluasi tugas melalui Planning Poker atau T-Shirt Sizing. Jika perbedaan > 2 SP — mereka mendiskusikan penyebabnya dan memberikan suara lagi. Aturan: jika tugas tidak dapat dievaluasi (persyaratan tidak jelas, tidak ada desain) — dikembalikan ke PO untuk direvisi dan akan datang ke grooming berikutnya dengan klarifikasi. Jangan mengevaluasi tugas dengan hal yang tidak diketahui — ini pasti akan menyebabkan kesalahan dalam sprint. Langkah 4: Pencatatan hasil (10 menit). PO mencatat evaluasi di Jira/Linear, memperbarui deskripsi tugas dan menetapkan prioritas.

Hasil grooming: 3-7 tugas yang sepenuhnya siap untuk Sprint Planning (dengan DoR, evaluasi, desain, API). PO memperbarui backlog: menghapus tugas usang, menggabungkan duplikat, memperjelas prioritas. Penting: grooming tidak mengakhiri pekerjaan PO — di antara sesi grooming ia harus menyiapkan tugas berikutnya. Kecepatan yang direkomendasikan: PO menyiapkan 3-4 tugas untuk grooming, tim memprosesnya. Jika ada lebih dari 50 tugas di backlog — PO harus melakukan prioritisasi (MoSCoW atau Weighted Shortest Job First) sebelum grooming.

Perbedaan grooming dengan Sprint Planning

Grooming — adalah persiapan. Tidak ada kewajiban — tugas hanya diperjelas dan dievaluasi. Sprint Planning — adalah komitmen. Tim memilih tugas dari yang telah disiapkan pada grooming dan berkomitmen untuk menyelesaikannya dalam sprint. Perbedaan utama: grooming tidak terikat pada sprint tertentu (refinement backlog secara umum), pada grooming tidak ada Sprint Goal, grooming dapat dilakukan kapan saja selama sprint. Sprint Planning — secara ketat di awal sprint dan selalu mengarah pada Sprint Goal.

Pada grooming, tugas hanya dievaluasi, tetapi tidak diambil ke dalam sprint. Pada Planning, tugas dipilih dari kumpulan yang telah disiapkan. Tanpa grooming, Sprint Planning memakan waktu 6-8 jam (bukan 4), karena tim melihat tugas untuk pertama kali dan tidak dapat mengevaluasinya dengan cepat. Aturan 80/20: 80% tugas pada Sprint Planning harus sepenuhnya siap (telah melalui grooming), 20% — bisa baru (bug mendesak, hotfix). Jika pada Planning ada lebih dari 20% tugas yang belum dievaluasi — grooming tidak memadai.

Kesalahan umum grooming

Kesalahan 1: grooming sebulan sekali. Tim mengumpulkan 3-4 sprint tugas, mencoba memperjelas semuanya dalam 2 jam. Hasil: setengah dari tugas tetap tidak dievaluasi, Planning memakan waktu seharian. Solusi: grooming harus teratur — 1 kali per sprint, 60 menit. Jika banyak tugas — tambahkan grooming kedua di tengah sprint. Lebih baik melakukan grooming lebih sedikit tugas tetapi berkualitas, daripada banyak — tetapi dangkal. Kecepatan: 3-5 tugas per satu grooming, masing-masing mendapat diskusi dan evaluasi penuh.

Kesalahan 2: evaluasi tanpa konteks. PO menunjukkan tugas „Implementasikan layar keranjang" tanpa desain, tanpa API, tanpa AC. Tim mengevaluasi „perkiraan" — 13 SP. Pada Planning ternyata sebenarnya 5 SP (karena layarnya sederhana). Solusi: tugas tidak dievaluasi jika tidak ada desain atau API. PO wajib menyiapkan materi sebelum grooming. Aturan: „Tidak ada mockup — tidak ada evaluasi". Pengecualian: tugas Spike — penelitian ketidakpastian, dievaluasi secara terpisah tanpa desain (2-5 SP tergantung kompleksitas penelitian).

Kesalahan 3: grooming berubah menjadi Planning. Tim mulai mendistribusikan tugas kepada pelaksana dan mendiskusikan siapa yang akan melakukan apa. Solusi: ingatkan bahwa grooming adalah untuk klarifikasi, bukan untuk distribusi. Distribusi — pada Daily setelah sprint dimulai. Grooming menjawab pertanyaan „apa yang harus dilakukan?", Planning — „kapan dilakukan?", Daily — „siapa yang melakukannya?". Mencampur pertanyaan-pertanyaan ini dalam satu pertemuan mengurangi efektivitas masing-masing. Scrum Master harus menghentikan diskusi Planning dan mengarahkan fokus pada klarifikasi tugas.

Kesalahan 4: mengabaikan Tech Debt. Pada grooming hanya fitur baru yang dibahas, tugas teknis diabaikan. Setelah 3-4 sprint, utang teknis menumpuk ke tingkat kritis. Solusi: pada setiap grooming setidaknya 1 tugas Tech harus dievaluasi. Proporsi: setiap 3 fitur → 1 tugas teknis. Gunakan metrik Tech Debt Ratio: rasio tugas Tech terhadap tugas Feature dalam sprint. Nilai target: 0.25-0.3 (25-30% waktu untuk utang teknis). Jika rasio di bawah 0.2 — kecepatan pengembangan akan menurun di sprint berikutnya.