Cara menulis task yang jelas dan siap dikerjakan

Ubah permintaan kabur menjadi task dengan konteks, scope, dan acceptance criteria yang bisa diuji. Termasuk template, contoh, dan format user story.

Task yang jelas mengurangi pertanyaan berulang saat pekerjaan dimulai. Sebuah judul belum cukup: orang yang mengerjakan perlu memahami masalah, hasil yang diharapkan, dan batas perubahan. Task yang kabur biasanya baru ketahuan bermasalah di akhir, ketika hasilnya tidak sesuai harapan dan pekerjaan harus diulang.

Panduan ini berisi format ringan yang bisa dibaca dalam beberapa menit, contoh untuk tim produk dan non-teknis, serta cara memakai user story dan acceptance criteria.

Mengapa task yang kabur mahal

Permintaan seperti “benahi login” atau “update halaman promo” terlihat sederhana. Masalahnya, setiap orang membayangkan hasil yang berbeda. Developer memperbaiki satu hal, pemberi permintaan mengharapkan hal lain, dan penguji tidak tahu apa yang harus diperiksa.

Biaya task yang kabur jarang terlihat di awal. Biaya itu muncul sebagai pesan bolak-balik, review yang berulang, dan task yang kembali dari Done ke In Progress. Menulis lima menit lebih lama di awal biasanya menghemat berjam-jam di akhir.

Isi minimum sebuah task

• Judul yang menjelaskan hasil: apa yang berubah setelah task selesai.
• Konteks: siapa yang mengalami masalah dan pada situasi apa.
• Hasil yang diharapkan: perilaku atau keluaran yang harus ada.
• Scope: area yang termasuk, dan yang sengaja tidak termasuk.
• Acceptance criteria: langkah yang akan dipakai untuk memeriksa hasil.
• Ketergantungan: keputusan atau task lain yang perlu selesai lebih dahulu.

Tidak semua task membutuhkan semua bagian. Task kecil seperti “perbarui nomor telepon di footer” cukup dengan judul dan satu kriteria. Semakin besar risiko dan ketidakpastian, semakin lengkap isinya.

Judul: dari area kerja ke hasil

Judul yang baik bisa dipahami tanpa membuka task. Ini penting ketika task muncul di board, daftar, atau notifikasi.

Contoh: dari permintaan kabur ke task yang bisa diuji

Permintaan awal: “benahi login”. Setelah ditanyakan, masalahnya adalah sesi di laptop hilang ketika pengguna login dari ponsel.

Judul: Pertahankan sesi laptop setelah pengguna login dari ponsel.

Konteks: pengguna yang bekerja di laptop dan memeriksa notifikasi di ponsel terpaksa login ulang di laptop.

Langkah reproduksi: masuk dari laptop, masuk dari browser ponsel dengan akun yang sama, lalu muat ulang laptop.

Hasil yang diharapkan: kedua browser tetap dapat membuka workspace.

Acceptance criteria:

1. Login di laptop berhasil.
2. Login akun yang sama dari ponsel berhasil.
3. Memuat ulang laptop tetap membuka workspace.
4. Logout dari ponsel tidak menutup sesi laptop.
5. Browser yang sudah logout meminta login saat membuka halaman privat.

Contoh tersebut menjelaskan perilaku yang dapat diperiksa tanpa menentukan seluruh cara implementasi. Developer tetap dapat memilih pendekatan yang sesuai struktur aplikasi.

Contoh untuk tim non-teknis

Format yang sama berlaku untuk tim pemasaran, agensi, atau operasional.

Judul: Terbitkan tiga post Instagram untuk promo akhir bulan.

Konteks: promo berlangsung 25–31 Oktober. Materi foto sudah tersedia di folder bersama.

Scope: tiga feed post dan caption. Story dan iklan berbayar tidak termasuk.

Acceptance criteria:

• Caption sudah disetujui pemilik brand.
• Setiap post mencantumkan periode promo dan tautan katalog.
• Jadwal tayang 25, 27, dan 30 Oktober pukul 19.00.

User story dan acceptance criteria

Banyak tim agile menulis kebutuhan dalam format user story:

“Sebagai [jenis pengguna], saya ingin [kemampuan], agar [manfaat].”

Contoh: “Sebagai admin workspace, saya ingin mengundang rekan lewat email, agar mereka bisa bergabung tanpa saya membuatkan akun.”

User story membantu tim mengingat siapa yang dilayani dan mengapa. Namun, user story saja belum cukup untuk diuji. Lengkapi dengan acceptance criteria. Sebagian tim memakai format Given–When–Then:

• Given penerima punya undangan yang masih berlaku, when ia membuka tautan, then formulir pendaftaran tampil.
• Given undangan sudah kedaluwarsa, when penerima membuka tautan, then muncul pesan untuk meminta undangan baru.

Tidak semua task perlu ditulis sebagai user story. Perbaikan bug, pekerjaan teknis, atau task administratif lebih jelas ditulis langsung sebagai hasil.

Seberapa besar sebuah task?

Task yang baik bisa diselesaikan dalam satu sampai tiga hari kerja. Jika lebih besar, risikonya sulit dilihat dan progres tampak macet di board.

Tanda task perlu dipecah:

• Ada kata “dan” di judul yang menggabungkan dua hasil berbeda.
• Pemilik task tidak bisa memperkirakan kapan selesai.
• Acceptance criteria lebih dari delapan butir.
• Bagian-bagiannya bisa diuji atau dikirim secara terpisah.

Sub-task, checklist, dan relasi

• Checklist cocok untuk langkah-langkah kecil yang dikerjakan orang yang sama, misalnya kriteria pengujian.
• Sub-task cocok ketika bagian pekerjaan punya pemilik atau status sendiri, misalnya desain dan pengembangan.
• Relasi seperti “blocks” atau “blocked by” menandai ketergantungan antar task, sehingga hambatan terlihat sebelum terjadi.

Hindari memecah setiap langkah kecil menjadi task terpisah jika itu hanya menambah beban administrasi.

Template task yang bisa disalin

• Judul: [hasil yang berubah setelah task selesai]
• Konteks: [siapa, situasi apa, mengapa sekarang]
• Hasil yang diharapkan: [perilaku atau keluaran]
• Scope: [termasuk] / [tidak termasuk]
• Acceptance criteria: [daftar yang bisa diperiksa]
• Ketergantungan: [task atau keputusan lain]

Kesalahan yang sering terjadi

• Menulis solusi, bukan masalah. “Tambahkan tombol merah” membatasi pilihan. Jelaskan dulu masalahnya.
• Kriteria yang tidak bisa diuji. “Halaman lebih cepat” tidak bisa diperiksa. “Halaman produk tampil di bawah 2 detik pada koneksi 4G” bisa.
• Menaruh data sensitif. Jangan menaruh password produksi atau data pelanggan di deskripsi task; gunakan akun demo khusus.
• Tidak memperbarui task saat keputusan berubah. Kriteria lama yang masih tertulis akan membingungkan penguji.

Pertanyaan yang sering diajukan

Siapa yang sebaiknya menulis task?

Siapa pun yang meminta pekerjaan bisa menulis draf task. Namun, task baru dianggap siap setelah pemilik prioritas dan orang yang akan mengerjakannya sepakat tentang hasil dan acceptance criteria-nya.

Apakah setiap task perlu acceptance criteria?

Task yang kecil dan hasilnya jelas cukup dengan satu kalimat kriteria. Task yang menyentuh banyak bagian, melibatkan pihak lain, atau berisiko tinggi sebaiknya punya daftar kriteria yang bisa diuji.

Menerapkannya di Moovit

Buka detail task untuk mengisi deskripsi, checklist, sub-task, relasi, dan komentar. Perbarui kriteria ketika keputusan berubah, dan catat alasannya di komentar. Baca panduan Kanban board untuk menentukan kapan task layak masuk Ready, lalu mulai workspace untuk mencoba format ini.