Bagaimana Anda menangani permintaan untuk mengubah ruang lingkup di tengah Sprint?

Question

Accepted Answer

Default dalam Scrum adalah **melindungi Sprint Goal**: tidak ada perubahan yang harus ditambahkan yang membahayakannya. Tetapi Scrum tidak kaku — ruang lingkup dapat *dinegosiasikan kembali dengan Product Owner*, dan perubahan yang benar-benar mendesak dapat ditangani, dengan trade-off yang jelas.

## Kerangka kerja keputusan

```text
1. Does the new request threaten the Sprint Goal?
     NO  → can it wait for the next Sprint? Usually yes → backlog it.
     YES → talk to the Product Owner about trade-offs.
2. Is it a genuine emergency (prod down, legal, security)?
     YES → the PO may cancel/replace work; something must drop.
3. Make the trade-off visible: pulling X in means Y comes out.
```

## Contoh konkret

Di tengah Sprint, penjualan menginginkan laporan "kecil" yang baru. Scrum Master membantu tim dan Product Owner melihat bahwa itu tidak mendesak, jadi itu masuk ke atas backlog Sprint berikutnya alih-alih mengganggu tujuan saat ini.

## Jebakan umum

- Diam-diam menyerap pekerjaan tambahan, menghancurkan Sprint Goal dan menyembunyikannya.
- Mengatakan "tidak" dengan tegas tanpa jalan — Product Owner selalu dapat merundingkan ulang.
- Membiarkan setiap pemangku kepentingan menyuntikkan pekerjaan secara langsung, melewati Product Owner.

## Mengapa ini penting

Melindungi Sprint Goal adalah yang membuat Scrum dapat diprediksi; suntikan berkelanjutan mengubah Sprint menjadi daftar to-do yang kacau.

Menangani perubahan melalui Product Owner dengan trade-off yang eksplisit membuat tim tetap fokus sambil tetap responsif terhadap keadaan darurat yang sebenarnya.