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, hingga anti-pattern konkret yang harus kamu hindari.

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 — satuan nilai terkecil yang bisa didemonstrasikan dan dievaluasi.

Durasi sprint tersedia dalam beberapa pilihan, masing-masing punya trade-off:

Tiga sifat sprint yang tidak boleh dilanggar:

• Konsisten — durasi tidak berubah-ubah setiap kali ada tekanan deadline
• 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. Akibatnya, semua aktivitas sprint berjalan sebagai formalitas tanpa menghasilkan pembelajaran atau nilai yang nyata.

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.

// ✗ 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.

// ANTI-PATTERN: Sprint sebagai kontrak
  Sprint = janji yang harus dipenuhi 100%
  Jika ada task yang tidak selesai = tim gagal
  Velocity harus naik tiap sprint

// BENAR: Sprint sebagai eksperimen terkontrol
  Sprint = eksperimen untuk menguji asumsi dan menghasilkan value
  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 dan saling bergantung. Menghilangkan satu dari antaranya membuat sprint kehilangan mekanisme penting.

flowchart TD
    G[Backlog Refinement\ndi tengah sprint berjalan]
    P[Sprint Planning\nkickoff sprint]
    E[Sprint Execution\ndev + testing + daily scrum]
    T[Test / Scenario Review\nvalidasi internal]
    R[Sprint Review\nfeedback dari stakeholder]
    RT[Sprint Retrospective\nrefleksi cara kerja tim]

    G --> P --> E --> T --> R --> RT
    RT --> |sprint berikutnya| P
    G -.->|menyiapkan backlog| P

Keenam aktivitas ini bukan formalitas — masing-masing punya tujuan spesifik:

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 dalam Sesi Grooming #

Sesi grooming yang efektif bukan sekadar membaca daftar story satu per satu. Ada beberapa aktivitas substansial yang harus terjadi di dalamnya:

• Membahas user story secara detail bersama Product Owner untuk memastikan semua orang punya pemahaman yang sama
• Klarifikasi requirement yang ambigu sebelum masuk sprint, bukan saat sedang mengerjakan kode
• Memecah story besar (epic) menjadi story yang lebih kecil dan dapat diselesaikan dalam satu sprint
• Estimasi effort menggunakan Story Points — ini adalah diskusi teknis singkat, bukan pengisian form
• Mengidentifikasi dependency antar story dan risiko teknikal yang bisa menghambat eksekusi

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 (DoR)
REQUIREMENT:
  □ User story menggunakan format yang disepakati tim
  □ Acceptance criteria sudah ada, jelas, dan terukur
  □ Wireframe / design tersedia jika story melibatkan UI

TEKNIKAL:
  □ Story sudah dipecah — dapat diselesaikan dalam satu sprint
  □ Dependency sudah diidentifikasi (API tim lain, data dari tim data, dll)
  □ Estimasi Story Points sudah disepakati setelah diskusi teknis

BISNIS:
  □ Product Owner sudah memvalidasi relevansi story dengan roadmap saat ini
  □ Priority sudah ditetapkan relatif terhadap story lain di backlog

Anti-Pattern Backlog Refinement #

// ✗ Story diambil meski requirement masih ambigu
"Nanti kita cari tahu detailnya waktu ngoding aja"
// ✓ Story tidak boleh masuk sprint sampai acceptance criteria jelas

// ✗ Estimasi dilakukan tanpa diskusi teknis
"Story ini 3 poin, lanjut ke yang berikutnya"
// ✓ Estimasi adalah diskusi teknis singkat, bukan pengisian form angka

// ✗ Grooming hanya dihadiri Product Owner dan Scrum Master
// ✓ 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, backlog belum cukup di-refine.

Dua Pertanyaan Inti #

Sprint Planning diorganisasikan di sekitar dua pertanyaan yang harus dijawab sebelum tim memulai eksekusi:

flowchart LR
    A{Sprint Planning} --> B["What can be delivered?\n→ Pilih story dari backlog\n→ Tetapkan Sprint Goal"]
    A --> C["How will it be done?\n→ Breakdown story ke task teknis\n→ Diskusi pendekatan implementasi"]
    B --> D[Sprint Backlog terbentuk]
    C --> D

Menentukan Kapasitas Tim #

Salah satu langkah pertama Sprint Planning adalah menghitung kapasitas realistis. Banyak tim yang melewatkan ini dan langsung mengambil story sebanyak mungkin — yang berujung pada overcommit dan sprint yang selalu gagal.

// Contoh perhitungan kapasitas tim
Tim: 4 developer, sprint 2 minggu (10 hari kerja)
Asumsi jam kerja efektif: 8 jam/hari

Faktor pengurang per orang:
  - Meeting & sync: ~1 jam/hari
  - PTO Developer A: 2 hari
  - Sprint ceremony (planning, review, retro): ~3 jam total

Kapasitas aktual:
  Developer A: (8 hari × 7 jam) = 56 jam
  Developer B: (10 hari × 7 jam) = 70 jam
  Developer C: (10 hari × 7 jam) = 70 jam
  Developer D: (10 hari × 7 jam) = 70 jam

Total kapasitas: 266 jam
→ Konversi ke Story Points menggunakan velocity historis tim
→ Sisakan ~20% buffer untuk hal tak terduga dan code review

Kapasitas tim dihitung dari data aktual, bukan asumsi. Gunakan velocity sprint sebelumnya sebagai baseline. Tim baru yang belum punya data historis sebaiknya mengambil story lebih sedikit di sprint pertama, lalu kalibrasi dari sana.

Anti-Pattern Sprint Planning #

// ✗ Sprint Goal terlalu umum atau tidak ada sama sekali
Sprint Goal: "Mengerjakan backlog yang ada"
// ✓ Sprint Goal harus menjawab "mengapa sprint ini penting?"

// ✗ Overcommit karena tekanan dari manajemen atau stakeholder
"Stakeholder minta fitur X dan Y harus selesai sprint ini"
// ✓ Komitmen berdasarkan kapasitas dan data historis, bukan permintaan

// ✗ Planning berubah menjadi desain atau architecture meeting
"Kita harusnya pakai approach ini, coba diskusikan dulu architecture-nya..."
// ✓ Desain teknis dibahas di grooming — planning fokus pada scope dan goal

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, karena di sinilah semua rencana bertemu dengan realita.

Prinsip Finish Before Start #

Prinsip paling fundamental dalam eksekusi yang sehat adalah menyelesaikan satu story sebelum memulai yang lain:

// ANTI-PATTERN: Memulai banyak story sekaligus
Developer A: story 1 (50%), story 3 (30%), story 7 (10%)
→ Tidak ada yang selesai di tengah sprint
→ WIP (Work in Progress) menumpuk, sprint review tidak ada yang bisa didemonstrasikan

// BENAR: Fokus menyelesaikan satu story sebelum mulai yang lain
Developer A: story 1 (100%) → story 3 (70%) → ...
→ Increment bertambah setiap hari
→ Jika sprint berakhir lebih awal dari ekspektasi, selalu ada story yang benar-benar Done

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. Formatnya bisa fleksibel, tapi tujuannya selalu sama: tim mengetahui siapa mengerjakan apa dan apa yang menghambat.

// ✗ 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 untuk kolaborasi
"Endpoint A hampir selesai tapi butuh input dari [Dev B] soal format response.
Kalau kita bisa align sekarang, hari ini bisa selesai."

Jika tim sudah punya board yang selalu di-update, daily bisa difokuskan ke diskusi blocker dan koordinasi antar story yang saling bergantung — bukan sekadar membacakan status.

Menjaga Kualitas Selama Eksekusi #

Tekanan sprint sering membuat tim memotong jalan pintas di kualitas kode. Ini keputusan yang terasa murah di sprint ini tapi mahal di sprint-sprint berikutnya dalam bentuk bug produksi dan technical debt.

// Praktik yang tidak boleh dikompromikan selama eksekusi
  ✓ Unit test ditulis bersamaan dengan implementasi, bukan setelah selesai
  ✓ Code review dilakukan sebelum story dianggap Done
  ✓ Tidak ada kode "nanti diperbaiki" tanpa tiket yang jelas
  ✓ Jika menemukan bug di luar scope story, buat tiket baru — jangan diam-diam perbaiki
  ✓ Tidak ada merge ke branch utama tanpa CI pipeline yang lulus

Test / Scenario Review #

Test Scenario Review adalah aktivitas yang sering diabaikan atau dianggap sudah ter-cover oleh Sprint Review. Padahal keduanya berbeda fungsi: Test Scenario Review fokus pada validasi teknikal dan fungsional sebelum demo ke stakeholder, bukan pengganti feedback loop eksternal.

Mengapa Ini Penting #

Tim yang melewatkan Test Scenario Review sering mendapati bug atau edge case baru di Sprint Review — tepat di depan stakeholder. Selain merusak kepercayaan, ini juga membuang waktu seluruh peserta yang hadir.

sequenceDiagram
    participant Dev as Developer
    participant QA as QA Engineer
    participant PO as Product Owner
    participant Stake as Stakeholder

    Dev->>QA: Story selesai, masuk queue testing
    QA->>Dev: Bug ditemukan (dalam lingkungan internal)
    Dev->>QA: Bug diperbaiki
    QA->>PO: Scenario review — validasi acceptance criteria
    PO->>QA: Flow sesuai ekspektasi
    QA-->>Stake: Sprint Review — demo increment yang sudah tervalidasi
    Stake-->>PO: Feedback untuk backlog

Aktivitas yang Dilakukan #

Sesi ini biasanya melibatkan developer, QA, dan Product Owner — tiga perspektif berbeda untuk melihat fitur yang sama:

• Developer menjelaskan apa yang diimplementasikan dan asumsi teknikal yang dibuat
• QA menjalankan test case dan mendiskusikan edge case yang mungkin terlewat
• Product Owner memvalidasi apakah flow sesuai acceptance criteria yang sudah disepakati

Anti-Pattern Test Scenario Review #

// ✗ QA hanya jadi "bug finder" di H-1 sebelum Sprint Review
Testing dimulai terlambat → bug ditemukan tapi tidak ada waktu untuk perbaikan
// ✓ Testing dimulai segera setelah story pertama Done
Story selesai → langsung masuk queue testing → bug diperbaiki dalam sprint yang sama

// ✗ Acceptance criteria tidak dijadikan acuan testing
QA menulis test case sendiri tanpa merujuk acceptance criteria
→ Fitur "lulus QA" tapi tidak sesuai ekspektasi Product Owner
// ✓ 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. Kualitas sprint review sangat menentukan seberapa relevan backlog untuk sprint-sprint berikutnya.

Bedakan Sprint Review dengan Status Meeting #

Ini adalah kesalahan paling umum: Sprint Review dijalankan sebagai laporan angka, bukan demonstrasi increment nyata.

// ✗ 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 diterima stakeholder

// ✓ 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 konkret
→ Backlog diupdate berdasarkan insight baru yang didapat

Siapa yang Hadir #

Sprint Review paling efektif ketika pesertanya adalah orang-orang yang bisa memberikan keputusan bisnis dan feedback bermakna:

// ✓ Wajib hadir
  Seluruh tim Scrum (developer, QA, Scrum Master)
  Product Owner

// ✓ Disarankan hadir
  Stakeholder bisnis yang bisa memberikan feedback langsung
  End user jika memungkinkan (user testing ringan)

// ✗ Tidak perlu hadir
  Manager yang hanya mendengarkan laporan tanpa memberikan feedback
  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 — tim tahu increment ini relevan
• Backlog diperbarui berdasarkan feedback (ada story baru, prioritas berubah, atau story lama dihapus karena tidak relevan)
• Tim dan stakeholder aligned terhadap kondisi produk saat ini dan apa yang harus dikerjakan selanjutnya

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. Tim yang melewatkan retrospective adalah tim yang berhenti belajar.

Format yang Umum Digunakan #

Ada beberapa format yang bisa kamu gunakan. 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 Start / Stop / Continue sedikit lebih terstruktur dan memaksa tim membuat keputusan:

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

Untuk tim yang lebih matang, 4Ls bisa menghasilkan diskusi yang lebih dalam:

Liked    → Apa yang kamu sukai dari sprint ini?
Learned  → Apa yang kamu pelajari?
Lacked   → Apa yang kurang dan seharusnya ada?
Longed For → Apa yang kamu inginkan tapi belum ada?

Retrospective yang Efektif vs Formalitas Kosong #

// ✗ Retrospective yang menjadi formalitas
"Oke, kita sudah 45 menit, ada yang mau disampaikan? Tidak ada? Sampai ketemu sprint berikutnya."
→ Action item: tidak ada
→ Perubahan yang terjadi: tidak ada
→ Sprint berikutnya: masalah yang sama terulang

// ✓ 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 lebih dari 4 jam
Tracking: action item ini di-review di retrospective sprint berikutnya

Anti-Pattern Retrospective #

// ✗ Action item tidak punya owner dan deadline
"Kita perlu improve dokumentasi"
// ✓ Setiap action item punya owner dan deadline yang jelas
"[Developer A] akan membuat template dokumentasi teknikal sebelum Sprint Planning berikutnya"

// ✗ Retrospective berulang membahas masalah yang sama sprint demi sprint
Sprint 5, 6, 7, 8: "Testing selalu terburu-buru di akhir sprint"
→ Action item tidak pernah ditindaklanjuti atau tidak efektif
// ✓ Review action item dari retrospective sebelumnya di awal setiap sesi
"Sprint lalu kita komit untuk X — apakah sudah dilakukan? Hasilnya bagaimana?"

// ✗ Hanya masalah teknikal yang dibahas
// ✓ Proses, komunikasi, dan dinamika tim sama pentingnya dengan masalah teknikal

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 yang berulang.

Definition of Ready (DoR) #

DoR mendefinisikan kapan sebuah story layak masuk ke sprint. Story yang tidak memenuhi DoR tidak boleh diambil dalam Sprint Planning — sekeras apapun tekanan dari manajemen.

// Contoh DoR untuk tim web application

REQUIREMENT:
  □ User story ditulis dengan format yang disepakati tim
  □ Acceptance criteria sudah ada, jelas, dan terukur
  □ Wireframe / design tersedia jika story melibatkan perubahan 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 saat ini
  □ 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 — ia mencakup seluruh siklus dari kode sampai siap di-deploy ke production.

// Contoh DoD untuk tim yang deploy ke production

KODE:
  □ Kode sudah di-push ke branch utama (bukan hanya di branch lokal atau feature branch)
  □ Code review sudah dilakukan dan di-approve 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 contract
  □ README atau internal wiki diupdate jika ada perubahan konfigurasi

Mengapa DoR dan DoD Harus Dibuat Bersama Tim #

// ✗ DoR dan DoD dibuat oleh Scrum Master atau PO saja, lalu diumumkan ke tim
→ Tim tidak merasa memiliki
→ Tidak diikuti dengan konsisten
→ Jadi dokumen yang hanya ada di paper tapi tidak hidup di keseharian

// ✓ 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
→ Di-post di tempat yang mudah diakses — bukan hanya ada di Confluence yang tidak dibaca

Alur Lengkap Satu Sprint #

Untuk memvisualisasikan bagaimana semua aktivitas saling terhubung dalam satu siklus sprint dua minggu:

gantt
    title Alur Sprint 2 Minggu
    dateFormat  D
    axisFormat Hari ke-%d

    section Sprint N-1
    Grooming Sprint N           :done, g, 5, 2d

    section Sprint N
    Sprint Planning             :active, p, 1, 1d
    Sprint Execution            :e, 2, 7d
    Test / Scenario Review      :t, 7, 2d
    Sprint Review               :r, 10, 1d
    Sprint Retrospective        :rt, 10, 1d
    Grooming Sprint N+1         :gn, 6, 2d

Pola yang perlu diperhatikan:

• Grooming untuk sprint berikutnya dilakukan di tengah sprint berjalan — bukan saat sprint sudah hampir berakhir
• Testing dimulai sesegera mungkin setelah story pertama Done, bukan menunggu semua story selesai
• Sprint Review dan Retrospective terjadi di hari yang sama (hari terakhir sprint), tapi dengan fokus yang berbeda

Anti-Pattern yang Harus Dihindari #

Berikut anti-pattern level sprint — bukan hanya di satu aktivitas tertentu, tapi di cara pandang tim terhadap sprint secara keseluruhan:

// ✗ Sprint dipakai untuk menjanjikan fitur ke klien
"Fitur ini pasti selesai sprint ini, kita sudah masukkan ke sprint backlog"
// ✓ Sprint adalah komitmen internal tim, bukan janji ke eksternal

// ✗ Velocity dijadikan KPI kinerja developer individu
"Developer A velocity-nya 12 SP, Developer B cuma 8 SP — berarti A lebih produktif"
// ✓ Velocity adalah metrik tim, bukan individu. Story Point bukan jam kerja.

// ✗ Sprint Planning dilakukan tanpa data kapasitas
"Kita ambil semua yang ada di backlog, semoga cukup waktunya"
// ✓ Hitung kapasitas aktual terlebih dahulu, ambil story berdasarkan data historis

// ✗ Retrospective dilewati saat sprint sibuk
"Sprint ini padat, retro kita skip dulu ya"
// ✓ Sprint yang paling sibuk justru yang paling butuh retrospective

// ✗ Story carry-over tanpa analisis root cause
"Story ini belum selesai, langsung masukkan ke sprint berikutnya"
// ✓ Setiap carry-over dianalisis — apakah estimasi salah? Ada blocker yang bisa dicegah?

// ✗ Sprint dipakai sebagai alat tekanan ke developer
"Kamu harus selesaikan ini sebelum sprint berakhir, apapun yang terjadi"
// ✓ Sprint adalah alat kolaborasi, bukan alat tekanan manajemen

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 dan dipetakan

SPRINT PLANNING:
  □ Sprint Goal sudah ditetapkan dan dipahami seluruh tim
  □ Kapasitas dihitung berdasarkan data aktual (velocity historis + PTO)
  □ Tim tidak overcommit — ada buffer ~20% untuk hal tak terduga

SPRINT EXECUTION:
  □ Daily Scrum dilakukan setiap hari, maks 15 menit
  □ Blocker diangkat dan diselesaikan dalam hari yang sama
  □ Story dikerjakan satu per satu (finish before start)
  □ 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 nyata

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 terjaga)

DOD & DOR:
  □ Definition of Ready dipatuhi saat Sprint Planning
  □ Definition of Done dipatuhi sebelum story dianggap selesai
  □ DoR dan DoD di-review secara berkala (minimal tiap kuartal)

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 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 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.

← Sebelumnya: Avoid Over-Indexing   Berikutnya: Workflow →