Sprint #
Tim engineering yang serius bukan diukur dari berapa banyak task yang selesai tiap minggu, melainkan dari seberapa cepat mereka bisa belajar dan memberikan nilai nyata ke pengguna. Sprint — sebagai mekanisme inti Scrum — dirancang tepat untuk kebutuhan itu. Tapi dalam praktiknya, sprint sering dijalankan sebagai ritual administratif: planning, standup, review, retro — semua dilakukan, tapi esensinya hilang. Artikel ini membahas sprint secara menyeluruh: dari filosofi yang paling sering disalahpahami, seluruh aktivitas yang ada di dalamnya, sampai anti-pattern konkret yang harus dihindari tim kamu.
Apa Itu Sprint? #
Sprint adalah periode waktu tetap (time-boxed) di mana tim mengerjakan sekumpulan pekerjaan yang dipilih dari Product Backlog, lalu menghasilkan sesuatu yang selesai, teruji, dan siap dikirim. Inilah yang disebut Increment.
Durasi sprint umumnya:
Sprint 1 minggu → cocok untuk tim dengan ritme cepat dan backlog stabil
Sprint 2 minggu → paling umum, keseimbangan antara fleksibilitas dan fokus
Sprint 4 minggu → batas maksimum; lebih panjang dari ini bukan sprint, itu mini-waterfall
Tiga sifat sprint yang tidak boleh dilanggar:
- Konsisten — durasi tidak berubah-ubah tiap sprint
- Predictable — scope disesuaikan kapasitas tim, bukan keinginan stakeholder
- Iteratif & Incremental — setiap sprint menghasilkan sesuatu yang bisa dinilai, bukan “masih dalam progress”
Sprint yang durasinya berubah-ubah setiap kali ada tekanan deadline bukan sprint — itu firefighting yang dikemas dengan nama agile. Konsistensi durasi adalah fondasi predictability tim.
Tujuan Sprint — Bagian yang Paling Sering Disalahpahami #
Ini adalah sumber kegagalan terbesar penerapan Scrum. Banyak tim menjalankan semua ritualnya dengan tekun, tapi salah memahami mengapa sprint ada.
Sprint Bukan untuk Menghabiskan Task #
Coba perhatikan bagaimana sprint biasanya diukur di timmu:
// ANTI-PATTERN: Sprint diukur dari jumlah task yang selesai
Sprint 12 Summary:
✗ 23 dari 25 story selesai (92% completion rate)
✗ Velocity: 48 SP
✗ "Sprint sukses!"
// BENAR: Sprint diukur dari value yang dikirim dan learning yang didapat
Sprint 12 Summary:
✓ Sprint Goal: "User bisa checkout tanpa bantuan CS"
✓ Increment: flow checkout baru live di staging, siap demo ke stakeholder
✓ Insight: ternyata user kesulitan di step pembayaran — backlog diupdate
Sprint bertujuan untuk menghasilkan Increment yang bernilai dan mendapatkan feedback secepat mungkin, bukan menghabiskan semua item yang ada di sprint backlog.
Sprint Goal adalah Pusat Segalanya #
Sprint Goal adalah alasan kenapa sprint ini ada. Dia bukan daftar task yang harus dikerjakan — dia adalah masalah yang ingin diselesaikan atau value yang ingin diuji dalam sprint ini.
Contoh Sprint Goal yang baik vs buruk:
// ✗ Sprint Goal yang buruk — ini daftar task, bukan goal
"Implementasi fitur login, halaman profil, dan notifikasi email"
// ✓ Sprint Goal yang baik — ini masalah yang ingin diselesaikan
"User bisa membuat akun dan masuk ke aplikasi tanpa bantuan admin"
// ✗ Sprint Goal yang buruk — terlalu umum, tidak bisa diukur
"Meningkatkan performa aplikasi"
// ✓ Sprint Goal yang baik — spesifik dan terukur
"Mengurangi waktu load halaman utama dari 4 detik menjadi di bawah 1.5 detik"
Dengan Sprint Goal yang jelas, tim bisa melakukan trade-off saat ada hambatan. Jika story A dan B bisa diselesaikan tapi story C mengalami blocker, tim bisa memutuskan: apakah sprint goal masih bisa dicapai tanpa C? Tanpa Sprint Goal, semua story terasa sama pentingnya dan tidak ada dasar untuk membuat keputusan.
Sprint Adalah Eksperimen, Bukan Kontrak #
Pola pikir yang keliru memperlakukan sprint sebagai janji mutlak ke manajemen. Ini mengubah sprint menjadi sumber stres, overcommit, dan kode yang dikerjakan terburu-buru demi mengejar angka.
Pola pikir yang salah:
Sprint = kontrak yang harus dipenuhi 100%
Jika ada task yang tidak selesai = tim gagal
Velocity harus naik tiap sprint
Pola pikir yang benar:
Sprint = eksperimen terkontrol untuk menguji asumsi
Story boleh tidak selesai jika Sprint Goal tetap tercapai
Velocity adalah metrik observasi, bukan target KPI
Sprint memberikan ruang aman untuk mencoba solusi, menemukan masalah lebih awal, dan memperbaiki arah sebelum terlambat. Sprint yang baik boleh gagal secara teknis, tapi tidak boleh gagal untuk belajar.
Hubungan Sprint dengan Scrum #
Scrum adalah framework, sprint adalah container-nya. Di dalam satu sprint, ada serangkaian aktivitas yang terstruktur:
Satu Siklus Sprint
│
├── 1. Product Backlog Refinement (Grooming)
│ └── Dilakukan di tengah sprint berjalan, menyiapkan sprint berikutnya
│
├── 2. Sprint Planning
│ └── Kickoff sprint — menentukan apa yang dikerjakan dan bagaimana caranya
│
├── 3. Sprint Execution
│ ├── Development & Testing
│ └── Daily Scrum (harian, maks 15 menit)
│
├── 4. Test / Scenario Review
│ └── Validasi fitur dengan QA dan Product Owner
│
├── 5. Sprint Review
│ └── Demo ke stakeholder, kumpulkan feedback
│
└── 6. Sprint Retrospective
└── Refleksi internal tim, perbaiki cara kerja
Keenam aktivitas ini bukan formalitas — masing-masing punya tujuan spesifik yang saling melengkapi. Menghilangkan satu dari antaranya akan membuat sprint kehilangan mekanisme penting.
Product Backlog Refinement (Sprint Grooming) #
Banyak tim langsung masuk Sprint Planning tanpa persiapan backlog yang memadai. Akibatnya, planning menjadi panjang dan tidak produktif karena diskusi requirement yang seharusnya sudah selesai dilakukan di situ.
Grooming — atau Product Backlog Refinement — adalah aktivitas menyiapkan backlog agar story-story yang akan diambil di sprint berikutnya sudah jelas, sudah dipecah cukup kecil, dan sudah diestimasi.
Kapan dan Seberapa Sering #
Timing yang disarankan:
✓ Di pertengahan sprint berjalan (misalnya hari ke-5 dari sprint 2 minggu)
✓ 1–2 kali per sprint, masing-masing 1–1.5 jam
✓ Sebelum sprint mendekati akhir agar backlog selalu siap
Timing yang bermasalah:
✗ Grooming digabung dengan Sprint Planning (planning jadi 4+ jam)
✗ Grooming hanya dilakukan saat backlog sudah kosong (reaktif, tidak proaktif)
Aktivitas yang Dilakukan #
Sesi grooming yang efektif mencakup:
- Membahas user story secara detail bersama Product Owner
- Klarifikasi requirement yang ambigu sebelum masuk sprint
- Memecah story besar (epic) menjadi story yang lebih kecil dan bisa diselesaikan dalam satu sprint
- Estimasi effort menggunakan Story Points
- Mengidentifikasi dependency antar story dan risiko teknikal
Output yang Diharapkan #
Story yang keluar dari grooming harus memenuhi Definition of Ready (DoR) — kriteria yang menyatakan story siap untuk diambil tim. Tanpa DoR, story yang masuk sprint sering kali masih ambigu dan menjadi sumber blocker di tengah jalan.
Contoh Definition of Ready:
□ User story menggunakan format: "Sebagai [user], saya ingin [aksi], agar [value]"
□ Acceptance criteria sudah ada dan sudah divalidasi Product Owner
□ Story sudah dipecah — dapat diselesaikan dalam 1 sprint
□ Estimasi Story Points sudah disepakati tim
□ Dependency sudah diidentifikasi (apakah ada yang harus selesai duluan?)
□ Design / mockup tersedia jika diperlukan
Anti-Pattern Backlog Refinement #
// ✗ Anti-pattern 1: Story diambil meski requirement masih ambigu
"Nanti kita cari tahu detailnya waktu ngoding aja"
// ✓ Solusi: Story tidak boleh masuk sprint sampil acceptance criteria jelas
// ✗ Anti-pattern 2: Estimasi dilakukan tanpa diskusi teknis
"Story ini 3 poin, lanjut ke yang berikutnya"
// ✓ Solusi: Estimasi adalah diskusi teknis singkat, bukan pengisian form
// ✗ Anti-pattern 3: Grooming hanya dihadiri Product Owner dan Scrum Master
// ✓ Solusi: Developer harus hadir — mereka yang paling tahu kompleksitas teknisnya
Sprint Planning #
Sprint Planning adalah kickoff resmi setiap sprint. Di sinilah tim memutuskan apa yang akan dikerjakan dan bagaimana cara mengerjakannya selama sprint berlangsung.
Sprint Planning yang baik tidak lebih dari 2–4 jam untuk sprint 2 minggu. Jika lebih panjang dari itu, biasanya backlog belum cukup di-refine.
Dua Pertanyaan Inti #
Pertanyaan 1: What can be delivered in this sprint?
→ Tim dan Product Owner memilih story dari backlog berdasarkan kapasitas
→ Sprint Goal disepakati bersama
Pertanyaan 2: How will the work be done?
→ Tim breakdown story menjadi task teknis
→ Pendekatan implementasi didiskusikan di level tinggi
Menentukan Kapasitas Tim #
Salah satu langkah pertama Sprint Planning adalah menghitung kapasitas realistis. Banyak tim yang melewatkan ini dan langsung mengambil story sebanyak mungkin.
Contoh perhitungan kapasitas:
Tim: 4 developer, sprint 2 minggu (10 hari kerja)
Kapasitas ideal per orang: 8 jam/hari
Faktor pengurang:
- Meeting & sync: ~1 jam/hari/orang
- PTO/cuti: Developer A ambil 2 hari
- Sprint ceremony: ~3 jam total (planning, review, retro)
Kapasitas aktual:
- Developer A: (8 hari × 7 jam) = 56 jam
- Developer B, C, D: (10 hari × 7 jam) = 70 jam masing-masing
Total: 56 + (70 × 3) = 266 jam
Konversi ke Story Points berdasarkan velocity historis tim.
Anti-Pattern Sprint Planning #
// ✗ Anti-pattern 1: Sprint Goal terlalu umum atau tidak ada
Sprint Goal: "Mengerjakan backlog yang ada"
// ✓ Solusi: Sprint Goal harus menjawab "mengapa sprint ini penting?"
// ✗ Anti-pattern 2: Overcommit karena tekanan dari manajemen
"Stakeholder minta fitur X dan Y harus selesai sprint ini"
// ✓ Solusi: Komitmen berdasarkan kapasitas dan data historis, bukan permintaan
// ✗ Anti-pattern 3: Planning berubah menjadi desain meeting
"Kita harusnya pakai approach ini, tapi coba kita diskusikan dulu architecture-nya..."
// ✓ Solusi: Desain teknis dibahas di grooming atau di luar planning — planning fokus pada scope dan goal
Kapasitas tim dihitung dari data aktual, bukan asumsi. Gunakan velocity sprint sebelumnya sebagai baseline, bukan angka ideal. Tim baru yang belum punya data historis bisa mulai dengan mengambil story lebih sedikit di sprint pertama, lalu kalibrasi dari sana.
Sprint Execution #
Sprint Execution adalah fase di mana tim mengerjakan sprint backlog — dari baris pertama kode sampai fitur siap di-review. Ini fase terpanjang dan paling kritis dalam sprint.
Prinsip Dasar Eksekusi yang Sehat #
// ANTI-PATTERN: Memulai banyak story sekaligus
Developer A: story 1 (50%), story 3 (30%), story 7 (10%)
→ Tidak ada yang selesai di tengah sprint, semua menggantung
// BENAR: Fokus menyelesaikan satu story sebelum mulai yang lain
Developer A: story 1 (100%) → story 3 (60%) → ...
→ Increment bertambah setiap hari, ada progress yang nyata dan terukur
Prinsip “selesaikan dulu sebelum mulai yang lain” (finish before start) adalah pondasi eksekusi yang baik. Story yang 90% selesai tidak memberikan value — hanya story yang benar-benar Done yang bisa di-demo dan di-deploy.
Daily Scrum #
Daily Scrum adalah meeting harian maksimal 15 menit untuk mensinkronisasi pekerjaan tim — bukan status report ke manager. Tiga pertanyaan klasiknya:
1. Apa yang dikerjakan kemarin?
2. Apa yang akan dikerjakan hari ini?
3. Apakah ada blocker?
Tapi formatnya bukan yang penting — yang penting adalah tim mengetahui siapa mengerjakan apa dan apa yang menghambat. Jika tim sudah punya board yang selalu update, daily bisa difokuskan ke diskusi blocker dan koordinasi antar story yang saling bergantung.
// ✗ Daily Scrum yang salah: status update ke manager
"Kemarin saya implement endpoint A, sudah 70%. Hari ini lanjut endpoint A."
Manager: "Kenapa belum selesai? Estimasinya kan 2 hari."
// ✓ Daily Scrum yang benar: sinkronisasi tim
"Endpoint A hampir selesai tapi saya butuh input dari [Developer B] soal format response.
Kalau kita bisa align sekarang, hari ini bisa selesai."
Menjaga Kualitas Selama Eksekusi #
Tekanan sprint sering membuat tim memotong jalan pintas di kualitas kode. Ini adalah keputusan yang terasa murah di sprint ini tapi mahal di sprint-sprint berikutnya.
Praktik yang tidak boleh dikompromikan selama eksekusi:
✓ Unit test ditulis bersamaan dengan implementasi, bukan setelah
✓ Code review dilakukan sebelum story dianggap Done
✓ Tidak ada kode yang "nanti diperbaiki" tanpa tiket yang jelas
✓ Jika menemukan bug di luar scope story, buat tiket baru — jangan diam-diam perbaiki
Test / Scenario Review #
Test Scenario Review adalah aktivitas yang sering diabaikan atau dianggap sudah ter-cover oleh Sprint Review. Padahal keduanya berbeda: Test Scenario Review fokus pada validasi teknikal dan fungsional sebelum demo ke stakeholder, bukan pengganti feedback loop.
Mengapa Ini Penting #
Tim yang melewatkan Test Scenario Review sering mendapati bug atau edge case baru di Sprint Review — tepat di depan stakeholder. Selain tidak profesional, ini membuang waktu dan merusak kepercayaan.
Alur yang benar:
Sprint Execution
│
▼
Test / Scenario Review ← bug ditemukan di sini, dalam lingkungan internal
│
▼
Sprint Review ← demo ke stakeholder, increment sudah tervalidasi
Aktivitas yang Dilakukan #
Sesi ini biasanya melibatkan developer, QA, dan Product Owner — tiga perspektif yang berbeda untuk melihat fitur yang sama:
- Developer menjelaskan apa yang diimplementasikan dan asumsi teknikal yang dibuat
- QA menjalankan test case dan mendiskusikan edge case
- Product Owner memvalidasi apakah flow sesuai acceptance criteria
Anti-Pattern Test Scenario Review #
// ✗ Anti-pattern 1: QA hanya jadi "bug finder" di akhir sprint
Testing dimulai H-1 sebelum Sprint Review
→ Bug ditemukan tapi tidak ada waktu untuk perbaikan
// ✓ Solusi: Testing dimulai segera setelah story pertama Done
Story selesai → langsung masuk queue testing → bug diperbaiki dalam sprint yang sama
// ✗ Anti-pattern 2: Acceptance criteria tidak dijadikan acuan testing
QA menulis test case sendiri tanpa merujuk acceptance criteria
→ Fitur "lulus QA" tapi tidak sesuai ekspektasi Product Owner
// ✓ Solusi: Acceptance criteria adalah sumber kebenaran tunggal untuk testing
Sprint Review #
Sprint Review adalah momen tim menunjukkan hasil kerja sprint ke stakeholder dan mendapatkan feedback nyata. Ini bukan meeting internal — ini adalah feedback loop antara tim dengan dunia luar.
Bedakan Sprint Review dengan Status Meeting #
// ✗ Yang salah: Sprint Review sebagai laporan status
"Di sprint ini kami berhasil menyelesaikan 18 dari 20 story (90%).
Dua story carry over ke sprint berikutnya karena ada blocker teknikal."
→ Tidak ada demo, tidak ada feedback, tidak ada nilai
// ✓ Yang benar: Sprint Review sebagai feedback loop
"Ini adalah flow checkout baru yang kami buat sprint ini.
[Demo langsung di sistem]
Kami ingin tahu: apakah ini sudah sesuai ekspektasi? Ada yang perlu diubah?"
→ Stakeholder memberikan feedback, backlog diupdate berdasarkan insight baru
Siapa yang Hadir #
Sprint Review paling efektif ketika stakeholder yang hadir adalah orang yang bisa memberikan keputusan bisnis:
Wajib hadir:
✓ Seluruh tim Scrum (developer, QA, Scrum Master)
✓ Product Owner
Disarankan hadir:
✓ Stakeholder bisnis yang bisa memberikan feedback
✓ End user jika memungkinkan (user testing ringan)
Tidak perlu hadir:
✗ Manager yang hanya mendengarkan laporan
✗ Departemen yang tidak terlibat dengan increment sprint ini
Output Sprint Review #
Sprint Review yang sukses menghasilkan lebih dari sekadar validasi — ia menghasilkan arah yang lebih jelas untuk sprint berikutnya:
- Increment tervalidasi oleh stakeholder
- Backlog diperbarui berdasarkan feedback (bisa ada story baru, prioritas berubah, atau story lama dihapus karena tidak relevan)
- Tim dan stakeholder aligned terhadap kondisi produk saat ini
Sprint Retrospective #
Retrospective adalah satu-satunya aktivitas sprint yang sepenuhnya berfokus ke dalam: bukan ke produk, tapi ke cara tim bekerja. Ini adalah mekanisme utama Scrum untuk perbaikan berkelanjutan.
Format yang Umum Digunakan #
Format paling sederhana menggunakan tiga pertanyaan:
What went well? → Apa yang berjalan baik dan perlu dipertahankan?
What didn't go well? → Apa yang tidak berjalan baik dan perlu diperbaiki?
What can we try? → Action item konkret untuk sprint berikutnya?
Format lain yang populer adalah Start / Stop / Continue:
START: Hal baru yang perlu kita mulai lakukan
STOP: Hal yang sedang kita lakukan tapi tidak memberikan value
CONTINUE: Hal yang sudah berjalan baik dan perlu dilanjutkan
Retrospective yang Efektif vs Formalitas Kosong #
// ✗ Retrospective yang menjadi formalitas
"Oke, kita sudah 45 menit, ada yang mau disampaikan? Tidak ada? Oke, sampai ketemu sprint berikutnya."
→ Action item: tidak ada
→ Perubahan yang terjadi: tidak ada
// ✓ Retrospective yang menghasilkan perubahan nyata
Identifikasi masalah spesifik: "Code review sering menumpuk di akhir sprint"
Root cause: tidak ada SLA berapa lama review harus diberikan
Action item: "Mulai sprint ini, setiap PR harus dapat review pertama dalam 4 jam kerja"
Owner: [nama Developer] akan mengingatkan jika ada PR yang terbengkalai
→ Perubahan ini di-track di sprint berikutnya: apakah berhasil?
Anti-Pattern Retrospective #
// ✗ Anti-pattern 1: Action item tidak punya owner
"Kita perlu improve dokumentasi"
→ Tidak ada yang bertanggung jawab = tidak ada yang dikerjakan
// ✓ Solusi: Setiap action item punya owner dan deadline yang jelas
"[Developer A] akan membuat template dokumentasi teknikal sebelum Sprint Planning berikutnya"
// ✗ Anti-pattern 2: Retrospective berulang membahas masalah yang sama
Sprint 5, 6, 7, 8: "Testing selalu terburu-buru di akhir sprint"
→ Action item tidak pernah ditindaklanjuti atau tidak efektif
// ✓ Solusi: Review action item dari retrospective sebelumnya di awal sesi
"Sprint lalu kita komit untuk X — apakah sudah dilakukan? Hasilnya bagaimana?"
Retrospective yang tidak menghasilkan perubahan lebih berbahaya dari tidak ada retrospective sama sekali. Ia menciptakan sinisme — tim merasa suara mereka tidak didengar dan rapat hanya membuang waktu. Jika action item dari 3 retrospective terakhir belum dikerjakan, identifikasi dulu mengapa sebelum menambah action item baru.
Definition of Ready dan Definition of Done #
DoR dan DoD adalah dua kontrak tertulis yang membuat sprint bisa berjalan dengan prediktabel. Tanpa keduanya, “siap” dan “selesai” menjadi subjektif dan menjadi sumber konflik.
Definition of Ready (DoR) #
DoR mendefinisikan kapan sebuah story layak masuk ke sprint. Story yang tidak memenuhi DoR tidak boleh diambil dalam Sprint Planning.
Contoh Definition of Ready untuk tim web application:
REQUIREMENT:
□ User story sudah ditulis dengan format yang disepakati tim
□ Acceptance criteria sudah ada, jelas, dan terukur
□ Wireframe / design sudah tersedia (jika story melibatkan UI)
TEKNIKAL:
□ Story sudah di-breakdown — dapat diselesaikan dalam satu sprint
□ Dependency sudah diidentifikasi (API dari tim lain, data dari tim data, dll)
□ Estimasi Story Points sudah disepakati setelah diskusi teknis
BISNIS:
□ Product Owner sudah memvalidasi story ini masih relevan dengan roadmap
□ Priority sudah ditetapkan relatif terhadap story lain di backlog
Definition of Done (DoD) #
DoD mendefinisikan kapan sebuah story benar-benar selesai. “Selesai” bukan hanya kode yang berjalan di laptop developer.
Contoh Definition of Done untuk tim yang deploy ke production:
KODE:
□ Kode sudah di-push ke branch utama (bukan hanya di branch lokal)
□ Code review sudah dilakukan dan di-approve oleh minimal 1 developer lain
□ Tidak ada konflik merge yang belum diselesaikan
TESTING:
□ Unit test sudah ditulis untuk logika bisnis baru
□ Semua test (unit, integration) lulus di CI pipeline
□ QA sudah melakukan testing berdasarkan acceptance criteria
DEPLOYMENT & MONITORING:
□ Fitur sudah di-deploy ke staging environment
□ Smoke test di staging sudah dilakukan dan lulus
□ Log dan monitoring sudah dikonfigurasi untuk fitur baru (jika relevan)
DOKUMENTASI:
□ API documentation diupdate (jika ada perubahan API)
□ README atau internal wiki diupdate jika ada perubahan konfigurasi
Mengapa DoR dan DoD Harus Dibuat Bersama Tim #
// ✗ Anti-pattern: DoR dan DoD dibuat oleh Scrum Master atau PO saja
→ Tim tidak merasa memiliki, tidak diikuti dengan konsisten
// ✓ Solusi: DoR dan DoD dibuat dalam workshop bersama seluruh tim
→ Setiap anggota tim berkontribusi → lebih dipatuhi dan lebih relevan
→ Di-review dan diperbarui tiap kuartal atau saat ada perubahan stack teknologi
Alur Lengkap Satu Sprint #
Untuk memvisualisasikan bagaimana semua aktivitas saling terhubung:
Sprint N-1 (sedang berjalan)
│
├── Hari ke-5: Grooming Sprint N
│ └── Siapkan backlog untuk sprint berikutnya
│
└── Hari ke-10: Sprint N-1 berakhir
├── Sprint Review: demo ke stakeholder
└── Sprint Retrospective: refleksi internal tim
Sprint N dimulai
│
├── Hari ke-1: Sprint Planning
│ ├── Tetapkan Sprint Goal
│ ├── Pilih story dari backlog (berdasarkan kapasitas)
│ └── Breakdown story menjadi task teknis
│
├── Hari ke-2 s/d ke-9: Sprint Execution
│ ├── Development, testing, code review
│ ├── Daily Scrum setiap hari (maks 15 menit)
│ └── Test / Scenario Review di pertengahan hingga akhir eksekusi
│
└── Hari ke-10: Sprint N berakhir
├── Sprint Review
└── Sprint Retrospective
Anti-Pattern yang Harus Dihindari #
Berikut anti-pattern level sprint — bukan di satu aktivitas tertentu, tapi di cara pandang tim terhadap sprint secara keseluruhan:
// ✗ Anti-pattern 1: Sprint dipakai untuk menjanjikan fitur ke klien
"Fitur ini pasti selesai sprint ini, kita sudah masukkan ke sprint backlog"
// ✓ Solusi: Sprint adalah komitmen internal tim, bukan janji ke eksternal
// ✗ Anti-pattern 2: Velocity dijadikan KPI kinerja developer
"Developer A velocity-nya 12 SP, Developer B cuma 8 SP — berarti A lebih produktif"
// ✓ Solusi: Velocity adalah metrik tim, bukan individu. Story Point bukan jam kerja.
// ✗ Anti-pattern 3: Sprint Planning dilakukan tanpa data kapasitas
"Kita ambil semua yang ada di backlog, semoga cukup waktunya"
// ✓ Solusi: Hitung kapasitas aktual terlebih dahulu, ambil story berdasarkan data
// ✗ Anti-pattern 4: Retrospective dilewati saat sprint sibuk
"Sprint ini padat, retro kita skip dulu ya"
// ✓ Solusi: Sprint yang paling sibuk justru yang paling butuh retrospective
// ✗ Anti-pattern 5: Story carry-over tanpa analisis
"Story ini belum selesai, langsung masukkan ke sprint berikutnya"
// ✓ Solusi: Setiap carry-over harus dianalisis — apakah estimasi salah? Ada blocker yang bisa dicegah?
Checklist Sprint yang Sehat #
BACKLOG & GROOMING:
□ Backlog sudah di-refine sebelum Sprint Planning
□ Story yang masuk sprint sudah memenuhi Definition of Ready
□ Dependency antar story sudah diidentifikasi
SPRINT PLANNING:
□ Sprint Goal sudah ditetapkan dan dipahami seluruh tim
□ Kapasitas dihitung berdasarkan data aktual (velocity historis + PTO)
□ Tim tidak overcommit — ada buffer untuk hal tak terduga (~20%)
SPRINT EXECUTION:
□ Daily Scrum dilakukan setiap hari, maks 15 menit
□ Blocker diangkat dan diselesaikan dalam hari yang sama
□ Story dikerjakan satu per satu, bukan semua sekaligus
□ Code review tidak menumpuk di akhir sprint
TESTING & REVIEW:
□ Testing dimulai sejak story pertama Done, bukan di akhir sprint
□ Test Scenario Review dilakukan sebelum Sprint Review
□ Sprint Review melibatkan stakeholder yang bisa memberikan feedback
RETROSPECTIVE:
□ Retrospective dilakukan setiap sprint tanpa terkecuali
□ Action item punya owner dan timeline yang jelas
□ Action item dari retrospective sebelumnya di-review di awal sesi
□ Tim merasa aman untuk berbicara jujur (psychological safety)
Ringkasan #
- Sprint adalah eksperimen, bukan kontrak — komitmen pada Sprint Goal, bukan pada setiap item di backlog. Story boleh tidak selesai jika Sprint Goal tetap tercapai.
- Sprint Goal adalah pusat segalanya — tanpa Sprint Goal yang jelas, sprint hanya jadi daftar task tanpa arah. Sprint Goal yang baik menjawab “masalah apa yang diselesaikan sprint ini?”
- Grooming adalah investasi, bukan overhead — story yang masuk sprint tanpa persiapan menjadi sumber blocker dan overrun di tengah jalan.
- Kapasitas dihitung, bukan diasumsikan — overcommit adalah penyebab utama sprint gagal. Gunakan data velocity historis dan hitung PTO sebelum mengambil story.
- Daily Scrum adalah sinkronisasi tim, bukan laporan ke atasan — fokus pada blocker dan koordinasi, bukan progress report individual.
- Testing dimulai segera setelah story pertama Done — bukan H-1 sebelum Sprint Review. Bug yang ditemukan lebih awal jauh lebih murah untuk diperbaiki.
- Sprint Review adalah feedback loop nyata — bukan laporan status. Demo langsung ke stakeholder, kumpulkan feedback, update backlog berdasarkan insight baru.
- Retrospective tanpa action item adalah formalitas kosong — setiap masalah yang diidentifikasi harus punya tindakan konkret, owner, dan timeline.
- DoR dan DoD adalah kontrak tertulis tim — buat bersama, patuhi bersama, review secara berkala.
- Velocity adalah metrik observasi, bukan target — mengoptimalkan velocity tanpa mengoptimalkan value adalah bentuk cargo cult agile yang paling berbahaya.