Perencanaan Sprint selalu bertumpu pada satu asumsi yang jarang dipersoalkan: kapasitas adalah jumlah orang yang Anda miliki dikalikan dengan time box. Anda mengestimasi pekerjaan, membandingkannya dengan apa yang diselesaikan tim pada siklus sebelumnya, lalu berkomitmen pada scope yang muat.
Namun begitu Anda menempatkan Agent coding AI di dalam tim, persamaan itu berhenti menggambarkan kenyataan. Sebuah Agent bisa langsung mengambil Task begitu Task tersebut siap, bekerja paralel dengan Agent lain, dan kembali membawa diff beserta hasil pengujian sebelum standup tempat Anda berencana membahasnya. Kapasitas eksekusi membengkak drastis. Respons yang menggoda adalah berkomitmen pada scope yang lebih banyak, dan tim yang melakukannya biasanya baru menyadari mode kegagalannya di akhir siklus pertama: Sprint ditutup dengan tumpukan kode yang sudah selesai plus dinding perubahan yang belum di-review dan tidak sempat diterima siapa pun.
Itulah argumen yang dibawa tulisan ini: dengan adanya Agent di dalam tim, eksekusi bukan lagi hambatan Sprint — review manusialah yang menjadi hambatan Sprint. Rencanakan berdasarkan throughput penerimaan, bukan berdasarkan berapa banyak kode yang bisa diproduksi. Kita akan memakai Sprint di Sharkly sebagai mekanisme konkretnya, sekaligus menjaga argumen perencanaan tetap terpisah jelas dari fakta produk.
TL;DR
Sprint di Sharkly adalah sekumpulan Task yang dibatasi rentang waktu dan dimiliki oleh satu Space; Task tetap menjadi sumber eksekusi dan diskusi, sementara Sprint menambahkan jadwal, scope, dan pelaporan. Sprint bersifat opsional dan berjalan dalam salah satu dari dua mode: cadence Otomatis, di mana Sharkly memelihara jadwal dan meneruskan pekerjaan yang belum selesai ke depan, atau Manual, di mana People membuat, memulai, dan menyelesaikan Sprint secara eksplisit. Pelaporannya mencakup scope, pekerjaan yang dimulai dan diselesaikan, tingkat penyelesaian, kapasitas, serta riwayat burnup. Bagi tim hybrid manusia-Agent, pergeseran dalam perencanaan adalah ini: Agent memperbesar kapasitas eksekusi, tetapi penerimaan hasil tetap ada di tangan People, sehingga komitmen Sprint yang jujur dibatasi oleh seberapa banyak pekerjaan selesai yang bisa diterima reviewer Anda, bukan oleh seberapa banyak yang bisa dihasilkan Agent Anda.
Apa itu Sprint di Sharkly
Sprint adalah sekumpulan Task yang dibatasi rentang waktu dan dimiliki oleh satu Space. Sprint membantu tim merencanakan scope yang terfokus, melacak kemajuan, dan memutuskan apa yang terjadi pada pekerjaan yang belum selesai saat time box berakhir. Task tetap menjadi sumber eksekusi dan diskusi; Sprint menambahkan jadwal, scope, dan pelaporan di atasnya.
Dokumentasi memakai istilah Sprint, dan maknanya sama dengan yang dimaksud industri. Scrum Guide mendeskripsikan Sprint sebagai wadah berdurasi tetap tempat ide berubah menjadi nilai, dan versi Sharkly tetap menjaga garis keturunan itu. Yang diubah Sharkly adalah siapa yang menjalankan eksekusi di dalam rentang waktu tersebut.
Tiga batasan menjaga konsep ini tetap rapi:
- Satu Sprint hanya milik satu Space. Menempatkan Task ke dalam Sprint tidak mengubah kepemilikannya.
- Sprint bersifat opsional dan diaktifkan per Space. Space yang berpikir dalam alur berkelanjutan bisa sama sekali tidak mengaktifkannya.
- Sprint bukan Project dan bukan View. Gunakan Sprint ketika pertanyaannya adalah apa yang harus diselesaikan dalam rentang waktu tertentu. Gunakan Project untuk hasil yang mungkin membentang beberapa Sprint atau Space. Gunakan View untuk cara tersimpan dalam memeriksa Task.
Perbedaan terakhir itu benar-benar berperan di tim hybrid: Project menampung hasil akhirnya, Sprint menampung komitmen jangka pendek, dan View menampung irisan apa pun yang dibutuhkan tiap orang sehari-hari.
Cadence otomatis atau mode Manual
Saat Anda mengaktifkan Sprint untuk sebuah Space, Anda memilih salah satu dari dua mode siklus hidup. Pilihan ini mengubah perilaku siklus hidup, bukan kepemilikan Task.
Cadence otomatis menyerahkan kalender kepada Sharkly. Anda mengatur durasi Sprint, cooldown opsional, hari kerja awal, berapa banyak Sprint mendatang yang dipelihara, zona waktu, serta aturan yang menambahkan Task secara otomatis ketika Task masuk ke kategori status tertentu. Sharkly kemudian membuat Sprint mendatang, memulai dan menyelesaikannya sesuai jadwal, dan meneruskan pekerjaan yang belum selesai ke depan. Memulai Sprint mendatang lebih awal akan menyelesaikan Sprint yang sedang berjalan terlebih dahulu dan menggulirkan pekerjaannya yang belum selesai ke Sprint yang baru dimulai.
Mode Manual menyerahkan kendali siklus hidup kepada tim. People membuat Sprint terencana saat diperlukan, memulainya tanpa mengubah tanggal yang telah dikonfigurasi, menjalankan lebih dari satu Sprint aktif secara paralel, dan memilih ke mana Task yang belum selesai diarahkan saat penyelesaian. Pembuatan otomatis, rollover, cooldown, dan aturan penambahan berbasis status tetap nonaktif di mode Manual.
| Cadence otomatis | Mode Manual | |
|---|---|---|
| Jadwal | Sharkly membuat, memulai, dan menyelesaikan Sprint sesuai ritme yang dikonfigurasi | People membuat, memulai, dan menyelesaikan Sprint secara eksplisit |
| Pekerjaan belum selesai | Digulirkan ke Sprint berikutnya secara otomatis | Diarahkan saat penyelesaian: tanpa Sprint, ke Sprint lain, atau ke Sprint baru |
| Sprint aktif paralel | Satu Sprint berjalan per cadence | Lebih dari satu Sprint aktif diperbolehkan |
| Penerimaan Task | Aturan kategori status dapat menambahkan Task selama rentang waktu berjalan | Task ditambahkan oleh People melalui perencanaan, daftar, atau kolom Sprint |
| Paling cocok untuk | Ritme tetap yang ingin dipelihara tim tanpa seremoni | Siklus tidak teratur, rentang waktu berbasis rilis, atau upaya yang saling tumpang tindih |
Pilihan yang jujur: gunakan cadence otomatis ketika tim Anda berjalan dengan ritme tetap dan ingin mekanismenya dipelihara untuk mereka. Gunakan Manual ketika siklus Anda tidak teratur, ketika rilis alih-alih kalender yang menentukan rentang waktu Anda, atau ketika Anda perlu dua Sprint aktif sekaligus. Beralih ke Manual tetap mempertahankan Sprint yang ada tetapi menghentikan penjadwalan otomatis. Menonaktifkan Sprint sepenuhnya akan menyelesaikan Sprint yang aktif, menghapus Sprint mendatang, dan menyimpan data yang sudah selesai untuk pelaporan.
Bagaimana Task masuk, keluar, dan melewati Sprint
Sprint tampil dalam lima status tampilan: Current, Upcoming, Planned, Completed, dan Canceled. Sprint yang selesai dan dibatalkan dipindahkan ke arsip Space alih-alih memenuhi daftar perencanaan aktif.
Anda menambahkan atau memindahkan Task melalui kolom Sprint-nya, dari daftar Task, atau selama perencanaan Sprint. Dua aturan lebih penting daripada kelihatannya.
Pertama, sebuah Task boleh sama sekali tidak punya Sprint. Itu adalah tempat normal bagi pekerjaan Backlog dan bagi Task yang tidak dikomitkan ke rentang waktu mana pun.
Kedua, menambahkan Task ke sebuah Sprint tidak mengubah statusnya. Inilah aturan yang perlu diinternalisasi tim hybrid, karena di Sharkly kategori status Backlog adalah status parkir: membuat Task atau menugaskan Agent selama Task berada di Backlog tidak memulai eksekusi. Memindahkan Task keluar dari Backlog ke status siap inilah yang dapat menjalankan Agent yang ditugaskan. Jadi perencanaan Sprint dan pelepasan eksekusi adalah dua tuas yang terpisah. Anda bisa merencanakan seluruh Sprint pada hari Senin, dengan Agent yang sudah ditugaskan, dan tidak ada apa pun yang berjalan sampai setiap Task sengaja dipindahkan ke status siap. Automation berbasis perubahan status kemudian dapat menangani transisi yang ingin Anda standardisasi.
Satu aturan lagi melindungi riwayat Anda: hanya Task yang sudah selesai yang bisa ditambahkan ke Sprint sebelumnya. Ini memungkinkan koreksi historis tanpa pernah menempatkan pekerjaan yang belum selesai ke dalam periode yang sudah ditutup.
Soal tanggal, awal dan akhir Sprint terencana sama-sama bisa diedit, sedangkan untuk Sprint aktif tanggal mulainya tetap tetapi tanggal berakhirnya bisa diubah.
Apa yang diberitahukan pelaporan Sprint
Pelaporan Sprint mencakup jumlah Task dan, ketika Space mengaktifkan estimasi, total poin estimasi pada enam bacaan: scope, pekerjaan yang dimulai, pekerjaan yang diselesaikan, tingkat penyelesaian, kapasitas, dan riwayat burnup.
Kapasitas layak dicermati lebih dekat karena angka inilah yang menjadi jangkar percakapan perencanaan. Sharkly menurunkannya dari velocity Sprint yang baru-baru ini selesai ketika riwayatnya sudah cukup, dan jika tidak, kembali ke estimasi berdasarkan ukuran Space. Dokumentasi menyarankan agar angka ini diperlakukan sebagai masukan perencanaan, bukan jaminan, dan bagi tim hybrid peringatan itu bukan basa-basi: velocity yang diukur pada kohort yang hanya berisi manusia berhenti memprediksi apa pun pada minggu Anda menambahkan tiga Agent. Riwayat burnup sering kali lebih mengungkap. Jika scope selesai dalam ledakan awal lalu garisnya mendatar, berarti Agent Anda sudah selesai mengeksekusi dan reviewer Anda menghabiskan sisa Sprint untuk mengejar ketertinggalan.
Hambatan tim hybrid: rencanakan untuk review, bukan eksekusi
Semua yang ada di bagian ini adalah argumen perencanaan, bukan fitur produk. Sharkly menyediakan mekanisme Sprint di atas; bagaimana Anda mengisi Sprint adalah keputusan penilaian Anda sendiri.
Mulailah dari pembagian kerja. Agent meneliti, mengeksekusi, menguji, dan melaporkan. People menetapkan arah, memberi wewenang, dan menerima hasilnya. Dalam agentic coding, segala hal antara arah dan penerimaan bisa didelegasikan, tetapi penerimaannya tetap milik manusia. Agent yang menyelesaikan Task belum benar-benar menyelesaikannya dalam pengertian apa pun yang layak dihitung Sprint Anda: diff, hasil verifikasi, dan batasan yang diketahui kembali ke Task tersebut, dan masih ada orang yang harus membacanya lalu menerima, meminta perubahan, atau memutuskan penggabungannya.
Sekarang hitunglah. Misalkan tim berisi lima orang menambahkan Agent dan throughput eksekusinya menjadi tiga kali lipat. Throughput review tidak ikut tiga kali lipat; lima orang yang sama masih memegangnya, dan setiap perubahan yang diterima menuntut perhatian yang nyata. Rencanakan Sprint berdasarkan kapasitas eksekusi dan kelebihannya tidak berubah menjadi nilai yang dikirim. Ia berubah menjadi antrean pekerjaan yang belum di-review, dan perubahan yang belum di-review adalah persediaan, bukan kemajuan. Lebih buruk lagi, Sprint yang mendekati penutupan mendorong reviewer tepat ke jalan pintas yang membuat pengembangan dengan banyak Agent berbahaya: menerima output tanpa membacanya.
Jadi balikkan pertanyaan perencanaannya. Alih-alih menanyakan berapa banyak pekerjaan yang bisa dieksekusi tim dalam dua minggu, tanyakan berapa banyak pekerjaan Agent yang sudah selesai yang bisa diterima People Anda dalam dua minggu. Dalam praktiknya ini mengubah empat kebiasaan:
- Estimasi biaya review, bukan hanya biaya pembuatan. Task yang sepele bagi Agent untuk dieksekusi bisa tetap mahal untuk diterima.
- Batasi jumlah pekerjaan selesai-tetapi-belum-diterima yang berjalan bersamaan. Tentukan berapa banyak Task yang benar-benar bisa diterima setiap reviewer per Sprint dan berhenti merencanakan melebihi jumlah itu. Ini adalah kesepakatan kerja, bukan pengaturan di Sharkly, tetapi metrik penyelesaian akan memberi tahu Anda ketika sudah melampaui batas.
- Lepaskan eksekusi secara sengaja. Karena Backlog memarkir eksekusi, Anda bisa mengatur agar Task dimulai secara bertahap sehingga pekerjaan yang selesai datang dengan laju yang bisa dicerna reviewer, bukan menumpuk sekaligus di hari kedua.
- Baca tingkat penyelesaian sebagai angka review. Ketika burnup mendatar sementara Agent menganggur, hambatannya sudah mengumumkan dirinya sendiri. Itu tanda untuk menambah reviewer atau mengurangi komitmen, bukan menambah Agent.
Tak satu pun dari ini memperlambat Agent. Ini hanya mengarahkan mereka. Sprint yang direncanakan berdasarkan throughput penerimaan akan mengirimkan semua yang dikomitkannya, dan tidak pernah meminta seseorang menyetujui kode yang tidak sempat ia baca.
Merencanakan Sprint hybrid, langkah demi langkah
- Aktifkan Sprint untuk Space dan pilih modenya. Ritme tim yang stabil mengarah ke cadence otomatis; pekerjaan yang digerakkan rilis mengarah ke Manual.
- Bentuk scope-nya. Tarik Task kandidat ke Sprint mendatang melalui perencanaan Sprint atau kolom Sprint. Biarkan pekerjaan yang belum dikomitkan tetap tanpa Sprint.
- Tugaskan kedua sisi dari setiap Task. Sharkly memisahkan tanggung jawab manusia dari eksekusi Agent: People masuk ke kumpulan assignee, dan Agent atau Crew masuk ke satu slot eksekusi. Mengubah salah satunya tidak pernah mengubah yang lain.
- Tulis Task yang bisa ditindaklanjuti Agent. Deskripsinya harus memuat tujuan, batasan, dan kriteria penerimaan yang dibutuhkan orang atau Agent baru untuk melanjutkan.
- Lepaskan pekerjaan sesuai laju review. Pindahkan Task keluar dari Backlog saat kapasitas reviewer mulai longgar.
- Tutup dengan niat. Di mode Manual, pilih ke mana setiap Task yang belum selesai diarahkan. Di cadence otomatis, periksa apa yang digulirkan ke depan dan tanyakan apakah scope-nya terlalu besar atau review-nya terlalu lambat.
Disiplin yang lebih luas dalam menjalankan pekerjaan dengan cara ini dibahas di artikel pilar kami tentang AI agent project management; Sprint adalah irisan berbatas waktu dari sistem tersebut.
Jika Sprint Anda saat ini ada di Jira
Anda tidak perlu membangun ulang proses Anda untuk mencoba semua ini. Integrasi Jira milik Sharkly dapat mengimpor data Sprint Jira, dan ketika impor Sprint diaktifkan, Space tujuan bisa dialihkan ke mode Sprint Jira, sehingga cadence yang sudah dijalankan tim Anda ikut terbawa alih-alih dimulai dari nol. Panduan tentang menugaskan tiket Jira ke AI Agent menunjukkan gagasan yang sama pada tingkat satu tiket, dan dokumentasi Sharkly membahas konfigurasi Sprint serta integrasi Jira secara mendalam.
Mulailah lebih kecil daripada migrasi: aktifkan Sprint di satu Space, rencanakan satu rentang waktu dua minggu berdasarkan kapasitas penerimaan reviewer Anda yang sebenarnya, lalu bandingkan burnup-nya dengan siklus terakhir Anda yang hanya berisi manusia.
FAQ
Apakah saya wajib memakai Sprint di Sharkly?
Tidak. Sprint bersifat opsional dan diaktifkan per Space. Space yang lebih menyukai alur berkelanjutan bisa sama sekali tidak mengaktifkannya, dan bahkan ketika Sprint diaktifkan, sebuah Task boleh tidak punya Sprint sama sekali — itu keadaan normal bagi pekerjaan Backlog.
Apa yang terjadi pada Task yang belum selesai saat Sprint berakhir?
Di cadence otomatis, Sharkly menyelesaikan Sprint sesuai jadwal dan meneruskan pekerjaan yang belum selesai ke Sprint berikutnya. Di mode Manual, alur penyelesaian akan menanyakan ke mana Task yang belum selesai harus diarahkan: tanpa Sprint, ke Sprint lain yang aktif atau mendatang, atau ke Sprint yang baru dibuat.
Bisakah Agent mengerjakan Task Sprint secara otomatis?
Agent atau Crew yang ditetapkan sebagai assignee eksekusi sebuah Task dapat menjalankan pekerjaannya, tetapi keanggotaan dalam Sprint saja tidak pernah memulai apa pun. Backlog adalah status parkir, jadi menugaskan Agent ke Task yang ada di Backlog tidak memulai eksekusi; memindahkan Task ke status siap inilah yang dapat memulai prosesnya. Pemisahan itu memungkinkan Anda merencanakan Sprint secara penuh terlebih dahulu lalu melepaskan eksekusi sesuai laju yang bisa dicerna reviewer Anda.
Bagaimana Sharkly menghitung kapasitas Sprint?
Kapasitas menggunakan velocity Sprint yang baru-baru ini selesai ketika riwayatnya sudah cukup, dan jika tidak, kembali ke estimasi berdasarkan ukuran Space. Dokumentasi menyarankan memperlakukannya sebagai masukan perencanaan, bukan jaminan — hal yang dua kali lebih penting bagi tim hybrid, di mana velocity mengukur keseluruhan sistem, bukan hambatan review di dalamnya.
Bisakah saya menambahkan Task ke Sprint yang sudah berakhir?
Hanya Task yang sudah selesai yang bisa ditambahkan ke Sprint sebelumnya. Ini mendukung koreksi historis, misalnya mengkreditkan pekerjaan yang selesai di dalam rentang waktu tersebut tetapi tidak pernah tercatat, tanpa pernah menempatkan pekerjaan yang belum selesai ke dalam periode yang sudah ditutup.
