Sprint dalam pengembangan mobile: esensi, durasi, dan perencanaan

Apa itu sprint dalam pengembangan?

Sprint — interval waktu (timebox) dengan durasi tetap, di akhir mana tim memberikan inkremen produk yang siap digunakan. Konsep sprint adalah dasar Scrum, tetapi digunakan juga dalam kerangka Agile lain. Dalam pengembangan mobile, inkremen adalah build aplikasi yang dapat diinstal di perangkat, diuji, dan ditunjukkan kepada pemangku kepentingan. Sprint tidak dapat diperpanjang — jika tugas tidak selesai, mereka dipindahkan ke sprint berikutnya.

Fitur utama sprint adalah durasi tetap. Tim tidak mengubah tujuan sprint setelah disetujui. Ini memberikan prediktabilitas: pemangku kepentingan tahu kapan akan menerima hasil. Di dalam sprint, tim sendiri memutuskan cara mendistribusikan pekerjaan. Scrum Master melindungi tim dari campur tangan eksternal — tugas baru tidak ditambahkan ke sprint saat ini. Menurut Scrum Guide 2025, ini adalah satu-satunya cara untuk mempertahankan kecepatan pengembangan yang berkelanjutan (sustainable pace).

Sprint terdiri dari empat acara wajib: Sprint Planning (perencanaan), Daily Scrum (sinkronisasi harian), Sprint Review (demonstrasi hasil), Sprint Retrospective (analisis proses). Di antaranya — pekerjaan utama: pelaksanaan tugas, pengujian, code review. Durasi setiap acara proporsional dengan panjang sprint: untuk sprint 2 minggu, Planning — 4 jam, Review — 2 jam, Retro — 1.5 jam, Daily — 15 menit. Total ritual memakan waktu sekitar 8 jam per sprint — 10% waktu kerja tim.

Ritual Scrum sprint

Ritual Scrum (upacara/acara) — pertemuan terstruktur tim dalam rangka sprint. Sprint Planning — di awal, Daily Scrum — setiap hari, Sprint Review dan Retrospective — di akhir. Semua acara memiliki timebox (batas waktu). Scrum Master memastikan kepatuhan terhadap timebox dan fokus. Setiap ritual dihadiri oleh seluruh tim Scrum: Product Owner, Scrum Master, pengembang. Pengecualian — Daily Scrum (hanya pengembang yang berpartisipasi, PO dan SM — opsional).

Hubungan ritual dengan tahapan sprint: Planning memberikan arah (apa dan bagaimana kita lakukan), Daily menyinkronkan (siapa melakukan apa, blocker apa), Review menunjukkan hasil (apa yang dilakukan, apa yang tidak), Retrospective memperbaiki proses (bagaimana membuat sprint berikutnya lebih baik). Melewatkan retrospektif — kesalahan paling umum tim: ketika tenggat mendesak, justru Retro yang dikorbankan. Ini mengarah pada stagnasi proses dan pengulangan kesalahan yang sama. Penelitian Scrum.org (2025) menunjukkan: tim yang melakukan Retro setiap 2 minggu meningkatkan velocity 35% lebih cepat.

Sprint Planning: perencanaan iterasi

Sprint Planning — pertemuan tim di awal sprint di mana ditentukan apa yang akan dilakukan dan bagaimana. Product Owner menyajikan tugas prioritas dari Product Backlog. Tim menilai kapasitas (capacity — waktu tersedia dengan mempertimbangkan cuti, rapat, utang teknis) dan memilih tugas yang dapat diselesaikan dalam sprint. Hasil Planning — Sprint Goal (tujuan sprint) dan Sprint Backlog (daftar tugas). Sprint Goal dirumuskan sebagai kalimat pendek: “Mengimplementasikan layar pemesanan dan integrasi pembayaran”.

Velocity — kecepatan tim, diukur dalam story point per sprint. Rata-rata dari 3-5 sprint terakhir. Menurut Scrum.org (2025), tim 5 pengembang mobile (3 Android + 2 iOS) memiliki velocity 25-40 SP untuk sprint 2 minggu. Planning menggunakan velocity sebagai batas atas — mereka mengambil 10-15% lebih sedikit untuk tugas tak terduga (code review, insiden, bantuan ke tim lain). Capacity vs Velocity: capacity adalah “orang-jam”, velocity adalah “story point”. Capacity memperhitungkan cuti, sakit, rapat. Tingkat kehilangan tipikal (loss rate) — 25-30% waktu kerja digunakan untuk aktivitas non-kode.

Perencanaan dibagi menjadi dua bagian: “apa” (PO menjelaskan tugas, tim mengklarifikasi) — 2 jam, dan “bagaimana” (tim mendekomposisi dan memperkirakan) — 2 jam. Untuk proyek mobile, di bagian “bagaimana” dibahas: kompatibilitas dengan versi Android/iOS, kebutuhan feature flag, dampak pada ukuran APK/IPA, izin baru. Teknik Planning Poker digunakan untuk estimasi: setiap pengembang memberikan perkiraannya dalam story point (1, 2, 3, 5, 8, 13). Perbedaan > 2 unit — mereka mendiskusikan alasannya. Ini mengungkap risiko tersembunyi pada tahap perencanaan, bukan di tengah sprint.

Eksekusi sprint: Daily Standup dan pelacakan

Daily Scrum (Standup) — pertemuan harian 15 menit untuk sinkronisasi tim. Setiap peserta menjawab tiga pertanyaan: “Apa yang saya lakukan kemarin?”, “Apa yang saya rencanakan hari ini?”, “Blocker apa saja?”. Daily bukan laporan status untuk manajer, melainkan alat pengorganisasian mandiri tim. Jika selama Daily diketahui bahwa dua pengembang mengerjakan tugas yang sama — ini sinyal untuk reorganisasi. Penting: Daily tidak menyelesaikan masalah, tetapi mengidentifikasinya — untuk penyelesaian, rapat terpisah diadakan setelah Daily.

Scrum Board (papan sprint) — visualisasi Sprint Backlog. Kolom: To Do / In Progress / In Review / Done. Setiap tugas bergerak di papan. Burndown Chart — grafik sisa pekerjaan per hari sprint. Burndown ideal — garis lurus dari total SP ke 0. Burndown nyata — grafik bertahap dengan mempertimbangkan penutupan tugas. Burndown menurun (di bawah garis ideal) — kita terlambat. Sinyal masalah: jika di pertengahan sprint kurang dari 30% tugas selesai — diperlukan koreksi. Mungkin risiko tidak diperhitungkan atau tugas terlalu diperkirakan.

Untuk pengembangan mobile, pelacakan sprint dipengaruhi faktor spesifik: waktu build (membangun proyek Android di CI bisa memakan 30+ menit), menunggu moderasi App Store / Google Play (jika perlu memberikan build ke penguji melalui TestFlight), kompatibilitas dengan berbagai perangkat (pengujian pada 10+ model memakan waktu). Saran: alokasikan 1 hari buffer di akhir sprint untuk pengujian akhir dan build versi rilis. Ini mengurangi risiko sprint tidak selesai sebesar 40% menurut Mind the Product (2025).

Sprint Review dan Retrospective

Sprint Review — demonstrasi inkremen kepada pemangku kepentingan. Tim menunjukkan build aplikasi yang berfungsi, bukan slide. Durasi — 2 jam untuk sprint 2 minggu. Product Owner memeriksa kesesuaian dengan Acceptance Criteria. Pemangku kepentingan memberikan umpan balik yang dapat memengaruhi Product Backlog. Review bukan laporan, melainkan dialog: pemangku kepentingan dapat mengajukan pertanyaan dan mengusulkan perubahan. Aturan utama: Sprint Review tentang produk, bukan proses. Kami menunjukkan apa yang tercapai, bukan bagaimana kami melakukannya.

Sprint Retrospective — pertemuan internal tim untuk menganalisis sprint yang lalu. Format: Start Doing (apa yang mulai dilakukan), Stop Doing (apa yang dihentikan), Continue Doing (apa yang dilanjutkan). Durasi — 1.5 jam untuk sprint 2 minggu. Retrospective adalah ruang aman untuk mendiskusikan masalah. Aturan: di Retro tidak dibahas detail teknis (untuk itu ada rapat teknis). Hanya proses, komunikasi, alat, budaya. Scrum Master memfasilitasi pertemuan dan memastikan setiap peserta berbicara.

Hasil Retrospective — 1-3 perbaikan untuk sprint berikutnya. Jika tim mengidentifikasi masalah “Code review terlalu lama” — action item: “Tetapkan SLA untuk review — 4 jam. Jika review tidak dilakukan tepat waktu — pengembang mengingatkan di Slack”. Action Items harus konkret, terukur, dan ditugaskan ke orang tertentu. Menurut Atlassian (2025), tim yang menjalankan action items Retro meningkatkan velocity 15-25% dalam 3-4 sprint. Yang tidak menjalankan — berjalan di tempat.

Cara memilih durasi sprint

2 minggu — standar untuk pengembangan mobile. Keseimbangan optimal antara prediktabilitas dan fleksibilitas. Cukup: merencanakan, mengimplementasikan 3-5 fitur sedang, menguji, menunjukkan hasil. 1 minggu — untuk tim dengan kematangan proses tinggi dan CI/CD. Memerlukan keputusan cepat, birokrasi minimal. Cocok untuk startup tahap awal yang perlu bereksperimen cepat. Kekurangan: overhead tinggi untuk ritual (setiap minggu Planning + Review + Retro = 7.5 jam).

3-4 minggu — untuk proyek kompleks dengan integrasi perangkat keras (wearables, IoT, perangkat BLE), moderasi toko yang lama, atau migrasi besar (misalnya, transisi dari RxJava ke Coroutines). Sprint panjang memberi lebih banyak waktu untuk pengujian, tetapi meningkatkan risiko “efek air terjun” — tim kehilangan fleksibilitas Agile. Rekomendasi Scrum Guide: jangan melebihi 1 bulan. Jika sprint lebih lama — di Review akan terlalu banyak konteks, pemangku kepentingan tidak dapat memberikan umpan balik berkualitas.

Masalah umum sprint

Masalah 1: Scope Creep. Di tengah sprint, Product Owner menambahkan tugas baru “mendesak dan penting”. Tim setuju — dan sprint gagal. Solusi: Sprint Goal — kontrak. Setiap perubahan memerlukan peninjauan Sprint Goal, dan ini hanya mungkin dalam keadaan darurat. Tugas baru masuk ke Product Backlog dan sprint berikutnya. Jika tugas benar-benar kritis — Sprint Goal lama dibatalkan, sprint direncanakan ulang, tetapi ini pengecualian, bukan praktik. Frekuensi scope creep lebih dari 1 kali dalam 3 sprint — tanda Product Owner lemah.

Masalah 2: Tugas tidak selesai. Di akhir sprint, 50% tugas di In Progress, 20% di Review, hanya 30% Done. Penyebab: perkiraan kapasitas berlebihan, perkiraan kompleksitas kurang, bug tidak terencana. Solusi: analisis penyebab di Retro. Jika secara sistematis tidak dapat menyelesaikan — jangan tambah jumlah tugas di Planning, tetapi kurangi. Tim yang mengambil 20% lebih sedikit tugas menunjukkan persentase penyelesaian lebih tinggi (80%+ vs 50-60%). Daftar periksa untuk Planning: untuk setiap tugas periksa Acceptance Criteria, Definition of Ready, dan ketergantungan dengan tugas lain.

Masalah 3: Retro formal. Tim melakukan Retro untuk formalitas — 15 menit, frasa umum, tanpa action items. Solusi: ubah format setiap Retro. Metode: Sailboat (apa yang memperlambat, apa yang mempercepat), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Tetapkan action items dengan tenggat dan penanggung jawab. Di awal Retro berikutnya, periksa pelaksanaan action items sebelumnya. Menurut Atlassian (2025), tim yang menggunakan format Retro berbeda menghasilkan 50% lebih banyak wawasan berguna.