Perencanaan Sprint untuk tim manusia-agen berhasil bila Anda merencanakannya berdasarkan kapasitas tinjauan, bukan kecepatan eksekusi. Agen bisa mengambil dan menyelesaikan lebih banyak Tugas daripada yang sanggup diterima para peninjau, jadi batas nyata sebuah siklus adalah berapa banyak perubahan selesai yang bisa diperiksa dan di-merge oleh manusia, bukan berapa banyak kode yang ditulis. Panduan ini mengurai metode perencanaannya langkah demi langkah, menyebutkan mode kegagalan di tiap langkah, dan ditutup dengan checklist yang bisa Anda jalankan sebelum Sprint berikutnya.
Perencanaan sprint klasik mengasumsikan sumber daya yang langka adalah jam kerja engineer untuk menulis kode. Tambahkan agen coding, dan asumsi itu langsung runtuh. Claude Code, Codex, dan Gemini CLI masing-masing bisa mengambil sebuah Tugas dan mengembalikan diff yang berfungsi bahkan saat Anda masih membaca hasil sebelumnya. Eksekusi bukan lagi hambatannya. Penerimaanlah yang menjadi hambatan.
Pergeseran itu diam-diam merusak rencana yang normal. Anda mengukur siklus dua minggu berdasarkan hari-developer, agen menghabiskan backlog dalam tiga hari, dan antrean perubahan yang sudah selesai tapi belum ditinjau menumpuk di belakang satu atau dua orang yang bisa menerima merge-nya. Sprint-nya terlihat cepat, tapi selesainya lambat.
Sharkly adalah workspace yang menjadi dasar perencanaan dalam panduan ini. Anda sudah punya agen coding; Sharkly mengubahnya menjadi tim dengan menyimpan setiap Tugas, progresnya, hambatannya, hasilnya, dan tinjauan manusianya di satu tempat bersama, bukan tersebar di berbagai terminal. Sprint di Sharkly adalah kumpulan Tugas dengan batas waktu yang dimiliki oleh satu Space. Metode di bawah ini sama saja, baik Anda menjalankannya di papan tulis maupun di dalam produk, tapi mode kegagalannya lebih mudah ditangkap begitu pekerjaan kembali ke papan bersama.
Apa yang berubah saat agen yang melakukan eksekusi
Perencanaan Sprint untuk tim manusia-agen adalah praktik membatasi lingkup siklus berdasarkan berapa banyak pekerjaan agen yang sudah selesai yang bisa ditinjau dan diterima manusia, bukan berdasarkan berapa banyak kode yang bisa dihasilkan tim.
Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Pembagian itulah inti dari seluruh persoalan perencanaan. Throughput agen Anda bersifat elastis: Anda bisa menjalankan tiga atau sepuluh. Throughput tinjauan Anda dibatasi oleh jumlah orang yang bisa membaca diff, menjalankan perubahannya, dan memutuskan bahwa itu layak rilis. Lihat perhitungan kapasitas tinjauan untuk memahami mengapa lonjakan output agen sebesar 5x jarang berarti pekerjaan yang dirilis 5x lebih banyak.
Jadi angka pertama yang Anda pakai untuk merencanakan bukanlah story point. Melainkan slot tinjauan: berapa banyak Tugas selesai yang bisa diterima setiap peninjau per hari, dikalikan jumlah peninjau, dikalikan jumlah hari dalam siklus. Semua hal lain harus muat di bawah plafon tersebut.
Rencanakan Sprint langkah demi langkah
1. Tetapkan plafon tinjauan lebih dulu. Perkirakan jumlah Tugas selesai yang benar-benar sanggup diterima seorang peninjau per hari; tinjauan sungguhan atas perubahan yang tidak sepele memakan waktu 30 sampai 60 menit. Kalikan dengan jumlah peninjau dan jumlah hari Sprint. Mode kegagalan: melewati langkah ini, merencanakan berdasarkan kapasitas agen, terlalu banyak berkomitmen, dan mengakhiri siklus dengan antrean tinjauan yang lebih panjang daripada Sprint itu sendiri.
2. Ukur Tugas untuk tinjauan, bukan untuk eksekusi. Pecah pekerjaan sehingga setiap Tugas menghasilkan diff yang bisa dipahami utuh oleh satu orang. Mode kegagalan: agen dengan senang hati mengembalikan perubahan 2.000 baris di sembilan file, tidak ada yang bisa menerimanya dalam satu slot, dan perubahan itu membusuk di dasar papan.
3. Tulis kriteria penerimaan sebelum menugaskan. Setiap Tugas membutuhkan definisi selesai yang bisa diuji: apa yang harus dibangun, seperti apa bentuk “benar”, dan apa yang tidak boleh disentuh. Mode kegagalan: lingkup yang kabur membuat agen menebak-nebak, peninjau mengembalikannya, dan satu Tugas menghabiskan dua slot tinjauan.
4. Tugaskan ke satu Agen atau sebuah Crew, secara sengaja. Gunakan satu Agen untuk pekerjaan kecil yang sudah terdefinisi dengan baik. Gunakan Crew ketika Agen pemimpin harus menafsirkan tujuan, menarik anggota lain, dan menyatukan hasil mereka kembali ke dalam satu Tugas. Mode kegagalan: memilih Crew untuk pekerjaan sepele justru menambah bagian yang bergerak, yang kemudian harus Anda tinjau.
5. Batasi pekerjaan yang sedang berjalan. Tetapkan batas berapa banyak Tugas yang boleh berada di kolom “sedang ditinjau”, seperti cara batas WIP bekerja di kanban. Mode kegagalan: tanpa batas, agen membanjiri kolom tinjauan lebih cepat daripada manusia mengosongkannya; hambatannya tetap tak terlihat sampai hari terakhir.
6. Sisakan buffer kelonggaran. Sisihkan slot tinjauan untuk pengerjaan ulang dan untuk permintaan perubahan yang akan Anda kembalikan. Mode kegagalan: merencanakan sampai 100% dan putaran pertama “tolong perbaiki” tidak punya tempat untuk mendarat.
Di titik mana spreadsheet atau setup tiket-saja berhenti bisa diskalakan
Anda bisa menjalankan Sprint pertama di spreadsheet. Satu tab berisi Tugas, satu kolom pemilik, satu kolom status. Semuanya masih berjalan selama satu orang menjalankan dua agen di satu repo.
Semuanya berhenti berfungsi begitu eksekusi dan pelacakan terpisah. Proses jalan agen, diff, output pengujian, dan diskusinya berada di terminal; spreadsheet hanya menyimpan status “sedang berjalan” yang sudah basi. Ada yang memperbarui barisnya secara manual, atau tidak ada yang melakukannya. Tambahkan agen ketiga di repo kedua, dan papan itu menyimpang dari kenyataan dalam sehari. Lalu Anda tidak bisa menjawab satu pertanyaan yang menjadi dasar perencanaan: apa yang sudah selesai, dan apa yang menunggu saya?
Papan tugas yang dibangun untuk ini menyatukan eksekusi dan catatannya. Pekerjaan, progres, hambatan, dan hasil kembali ke Tugas, bukan menghilang ke dalam sesi privat. Di Sharkly, sebuah Agen mengambil Tugas yang sudah siap, berjalan di worktree terisolasi agar perubahan paralel tidak bertabrakan, lalu ringkasan perubahannya, hasil verifikasi, dan batasan yang diketahui kembali ke timeline Tugas untuk diterima atau dikembalikan oleh manusia. Itulah perbedaan antara status yang Anda pelihara sendiri dan status yang memelihara dirinya sendiri. Ini juga memberi sesi perencanaan berikutnya data nyata: pekerjaan apa yang diselesaikan agen pada siklus sebelumnya, dan ke mana waktu tinjauan pergi.
Batas yang jujur: jika Anda menjalankan satu agen di satu repo dan meninjau sambil jalan, Anda tidak perlu papan tugas atau Sharkly untuk itu. Satu terminal dan sebuah checklist sudah cukup. Persamaannya berubah ketika Anda merencanakan lintas beberapa agen, Tugas, repositori, atau orang — tepat di titik itulah spreadsheet berubah menjadi pekerjaan kedua. Sharkly dibangun untuk kasus kedua itu; unduh Sharkly ketika spreadsheet mulai berbohong kepada Anda.
Checklist yang perlu dijalankan sebelum Sprint berikutnya
Jalankan ini sebelum Anda menetapkan rencananya:
- [ ] Menghitung plafon tinjauan (peninjau x penerimaan per hari x hari) dan memperlakukannya sebagai kapasitas nyata Sprint.
- [ ] Setiap Tugas cukup kecil untuk ditinjau dalam satu slot.
- [ ] Setiap Tugas punya kriteria penerimaan yang bisa diuji dan batas “jangan disentuh” yang jelas.
- [ ] Setiap Tugas ditugaskan ke satu Agen atau sebuah Crew secara sengaja, bukan karena default.
- [ ] Ada batas WIP pada kolom “sedang ditinjau”.
- [ ] Kelonggaran disisihkan untuk pengerjaan ulang dan permintaan perubahan.
- [ ] Manusia memegang keputusan merge dan rilis untuk setiap Tugas.
- [ ] Progres, hambatan, dan hasil kembali ke papan bersama, bukan ke terminal privat.
Centang kedelapan poin itu dan eksekusi agen tetap berada dalam rencana yang bisa diselesaikan tim. Lewati poin pertama dan sisanya tidak akan menyelamatkan Anda.
FAQ
Apakah perencanaan sprint masih berguna ketika agen menulis sebagian besar kode? Ya, tapi batasannya bergeser. Sprint tidak lagi menjadi wadah untuk jam kerja engineering, melainkan wadah untuk tinjauan dan penerimaan. Rencanakan siklus berdasarkan berapa banyak pekerjaan selesai yang bisa diperiksa orang, dan agen akan mengisinya. Scrum Guide masih mendefinisikan seremoninya; hanya perhitungan kapasitasnya yang berubah.
Bagaimana cara memperkirakan kapasitas untuk tim manusia-agen? Mulailah dari peninjau, bukan dari agen. Hitung Tugas selesai yang benar-benar sanggup diterima satu orang per hari, lalu kalikan dengan jumlah peninjau dan hari Sprint. Jumlah agen hanya relevan sampai melewati plafon tersebut; setelah itu, agen yang lebih banyak hanya memperbesar antrean.
Apakah agen sebaiknya memilih Tugasnya sendiri selama Sprint? Biarkan mereka mengambil Tugas yang sudah siap dan sudah dilengkapi kriteria penerimaan, sehingga pekerjaan paralel berjalan tanpa perlu dispatcher. Biarkan manusia menangani arah, wewenang, dan merge. Dengan begitu, human in the loop tetap ada di tempat yang membutuhkan penilaian, dan otomatis di tempat lainnya.
Apa bedanya dengan manajemen proyek biasa? Seremoninya terlihat sama; hambatannya tidak. Manajemen proyek agen AI merencanakan berdasarkan throughput tinjauan dan isolasi perubahan, bukan ketersediaan developer, karena eksekusi bukan lagi sumber daya yang langka.
Apakah saya perlu alat baru, atau bisa memperluas Jira? Anda bisa tetap memakai sistem yang sudah dipahami tim Anda. Celahnya adalah alat tiket melacak status yang diketik manusia, bukan eksekusi yang dijalankan mesin. Lihat alternatif Jira untuk tim manusia-agen untuk melihat di mana celah itu mulai terasa mengganggu.
