Belajar Scrum Master - Sprint Review & Feedback
Memahami Sprint Review secara mendalam: bagaimana memfasilitasi review yang efektif, mendemonstrasikan outcome yang bermakna, mengumpulkan feedback dari stakeholder, dan mengubah review dari presentasi formal menjadi percakapan produktif
#Pendahuluan
Setelah di episode 8 kita memahami Daily Scrum & Facilitation, pada episode ini kita masuk ke Sprint Review — event di mana tim mendemonstrasikan hasil kerja kepada stakeholder dan mengumpulkan feedback. Review bukan presentasi formal, melainkan percakapan produktif tentang apa yang sudah tercapai dan apa yang perlu diubah.
Mengapa review kritis? Karena tanpa feedback dari stakeholder, tim berjalan dalam kegelapan. Review adalah jembatan antara apa yang tim kerjakan dan apa yang stakeholder butuhkan. Review yang efektif menghasilkan adaptasi yang bermakna; review yang buruk hanya membuang waktu.
#Struktur Sprint Review
| Fase | Durasi | Aktivitas |
|---|---|---|
| Review goal | 5 menit | PO menjelaskan sprint goal |
| Demo | 30-40 menit | Tim mendemonstrasikan hasil |
| Feedback | 20-30 menit | Stakeholder memberikan masukan |
| Adaptasi | 10-15 menit | PO mempertimbangkan perubahan backlog |
#Demo yang Efektif
#Yang Harus Didemo
| Tipe | Contoh |
|---|---|
| Working software | Fitur yang bisa dicoba langsung |
| Outcome | User bisa checkout tanpa friction |
| Experiment | A/B test menunjukkan peningkatan |
#Yang TIDAK Harus Didemo
| Tipe | Mengapa Tidak |
|---|---|
| Code | Stakeholder tidak peduli |
| Task list | Bukan demo, itu status report |
| Partial work | Membingungkan |
Tip
Jangan biarkan review menjadi presentasi slide. Gunakan working software langsung — browser, staging environment, atau prototipe interaktif. Stakeholder belajar lebih banyak dengan melihat dan mencoba daripada dengan mendengarkan.
#Mengumpulkan Feedback
#Teknik Feedback
| Teknik | Cara Kerja |
|---|---|
| 3Ls | Liked, Learned, Lacked |
| Start-Stop-Continue | Apa yang harus mulai, berhenti, dan dilanjutkan |
| Dot voting | Vote pada area yang perlu perubahan |
| Open discussion | Pertanyaan terbuka, tanpa struktur |
#Actionable Feedback
Feedback harus actionable (bisa ditindaklanjuti):
| Buruk | Baik |
|---|---|
| "Bagus" | "Checkout flow 30% lebih cepat dari sebelumnya" |
| "Perlu diperbaiki" | "Form registrasi perlu validasi email real-time" |
| "Kurang intuitif" | "Navigation mobile tidak memiliki back button" |
#Adaptasi Backlog
Review menghasilkan perubahan pada Product Backlog berdasarkan feedback:
- Feedback diterima: tambahkan item baru ke backlog.
- Feedback ditolak: dokumentasikan alasan.
- Feedback ditunda: tambahkan ke future sprint.
#Praktik: Review Checklist
[ ] Sprint goal dijelaskan di awal
[ ] Working software didemo (bukan slide)
[ ] Outcome (bukan sekadar output) ditunjukkan
[ ] Stakeholder yang tepat hadir
[ ] Feedback dikumpulkan secara terstruktur
[ ] Feedback actionable didokumentasikan
[ ] Perubahan backlog didasarkan pada feedback
[ ] Review time-boxed (maksimal 2 jam untuk sprint 4 minggu)#Penutup
Inti yang harus dibawa pulang:
- Sprint Review adalah percakapan produktif tentang hasil sprint.
- Demo harus working software, bukan slide atau code.
- Feedback harus actionable dan didokumentasikan.
- Adaptasi berarti mengubah backlog berdasarkan feedback.
Di episode 10 selanjutnya kita akan membahas Retrospective Techniques — berbagai format retro, cara menghasilkan action items yang efektif, dan bagaimana membangun budaya continuous improvement. Pastikan review kalian sudah efektif, karena retro akan merefleksikan seluruh sprint termasuk kualitas review!