Program Studi Bisnis Digital • FEB

Lab Startup Bisnis Digital

Pertemuan 8 — Metode Scrum & Manajemen Proyek

Setelah ide, model bisnis, dan proyeksi keuangan matang di tangan Anda — bagaimana caranya tim startup benar-benar mengerjakan produk secara terorganisir, cepat, dan tidak berantakan?

RPS MINGGU 9 • 2×50 MENIT

Selamat datang di pertemuan kedelapan. Sampai minggu lalu, Anda sudah merancang model bisnis, memahami pasar, merumuskan proposisi nilai, dan bahkan menghitung proyeksi keuangan startup Anda — sekarang kita masuk ke pertanyaan yang sangat praktis: bagaimana caranya tim benar-benar mengeksekusi semua rencana itu menjadi produk nyata, minggu demi minggu, tanpa kacau? Bayangkan tim lima orang membangun aplikasi UMKM digital seperti yang banyak dipakai pelaku usaha di Semarang untuk jualan online — tanpa metode kerja yang jelas, biasanya yang terjadi adalah rapat tanpa arah, fitur setengah jadi, dan deadline yang selalu meleset. Hari ini kita akan belajar Scrum, kerangka kerja manajemen proyek paling populer di industri startup dan teknologi dunia, termasuk yang dipakai tim produk di banyak startup Indonesia. Materi ini akan langsung Anda pakai di proyek akhir laboratorium ini, karena minggu depan kita mulai membangun prototipe produk sungguhan menggunakan cara kerja yang kita pelajari hari ini.

Bagian 1 dari 3

Dari Waterfall ke Scrum

Mengapa startup butuh cara kerja berbeda dari proyek konstruksi — dan apa sebenarnya Scrum itu.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menerapkan kerangka kerja Scrum untuk mengorganisir proyek pengembangan produk startup. Secara rinci:

CAPAIAN 1

KONSEP

Membedakan pendekatan waterfall dan agile, serta menjelaskan nilai & prinsip inti Scrum.

CAPAIAN 2

PERAN & ARTEFAK

Menjelaskan tiga peran Scrum dan tiga artefak utamanya secara tepat.

CAPAIAN 3

HITUNG

Menghitung kapasitas sprint dan membaca progres burndown tim.

CAPAIAN 4

TERAPKAN

Merancang sprint pertama untuk tim startup fiktif, lengkap dengan backlog awal.

Mengapa Scrum Penting untuk Startup?

Bayangkan tim Anda baru mulai membangun aplikasi pemesanan katering untuk UMKM. Tiga bulan pertama berjalan seperti ini:

MASALAH 1

ARAH KABUR

Semua fitur dikerjakan sekaligus tanpa prioritas — tidak ada yang selesai utuh.

MASALAH 2

BUTA PROGRES

Founder tidak tahu apakah tim on-track atau tertinggal sampai deadline dekat.

MASALAH 3

SULIT BERUBAH

Setelah 3 bulan, ternyata pengguna mau fitur berbeda — terlambat menyesuaikan.

Tiga masalah ini adalah alasan utama laporan industri global (mis. Standish Group CHAOS Report) konsisten menemukan proyek dengan pendekatan iteratif/agile punya tingkat keberhasilan jauh lebih tinggi dibanding proyek yang direncanakan kaku di awal tanpa jeda evaluasi.

Skenario ini sangat umum terjadi pada tim startup pemula, termasuk yang pernah saya temui dalam pendampingan startup mahasiswa. Masalah pertama, arah kabur, muncul karena tim mengerjakan semua ide bagus sekaligus tanpa urutan prioritas, sehingga di akhir bulan tidak ada satu pun fitur yang benar-benar siap dipakai pengguna. Masalah kedua lebih berbahaya lagi — founder atau investor baru sadar proyek tertinggal jauh justru ketika deadline sudah dekat, karena tidak ada titik pengecekan rutin. Masalah ketiga adalah soal fleksibilitas: kebutuhan pasar UMKM katering bisa berubah drastis begitu ada masukan pengguna nyata, tapi kalau rencana sudah dikunci kaku sejak awal, tim kesulitan menyesuaikan diri. Scrum dirancang khusus untuk menjawab ketiga masalah ini lewat siklus kerja pendek yang berulang, transparan, dan terbuka untuk berubah arah.

Waterfall vs Agile: Dua Filosofi Berbeda

Waterfall menyelesaikan tiap tahap penuh sebelum lanjut ke tahap berikut — produk baru terlihat di ujung. Agile (keluarga metode termasuk Scrum) merilis potongan kecil produk berulang kali, dengan evaluasi & penyesuaian di tiap putaran.

Diagram ini adalah inti perbedaan filosofi yang harus Anda pahami sebelum masuk ke detail Scrum. Waterfall, istilah yang artinya air terjun, menggambarkan proyek yang mengalir satu arah — analisis dulu tuntas, baru desain, baru dibangun, baru diuji, dan pengguna baru melihat hasilnya di akhir yang bisa memakan waktu berbulan-bulan. Model ini cocok untuk proyek dengan kebutuhan yang sudah sangat pasti sejak awal, misalnya membangun jembatan fisik, tapi berbahaya untuk startup digital karena kalau asumsi pasar di awal ternyata salah, kerugian waktu dan biayanya sangat besar. Agile, sebaliknya, memecah pekerjaan menjadi siklus pendek berulang yang disebut sprint, biasanya satu sampai empat minggu, di mana tim merilis sesuatu yang bisa dicoba pengguna lalu belajar dari umpan baliknya. Scrum adalah kerangka kerja paling terstruktur dan paling populer dalam keluarga agile ini, dan itulah yang akan kita bedah detailnya mulai slide berikutnya.

Apa itu Scrum?

Scrum adalah kerangka kerja ringan untuk mengelola pekerjaan kompleks secara bertahap lewat siklus pendek berulang yang disebut Sprint (biasanya 1–4 minggu), didasarkan pada tiga pilar:

PILAR 1

TRANSPARANSI

Progres & masalah kerja terlihat jelas oleh semua pihak — tidak ada yang disembunyikan.

PILAR 2

INSPEKSI

Tim rutin memeriksa hasil kerja & kemajuan menuju tujuan pada titik-titik tertentu.

PILAR 3

ADAPTASI

Kalau ada penyimpangan, tim segera menyesuaikan rencana — bukan menunggu akhir proyek.

Scrum bukan metodologi lengkap yang mengatur segalanya — ia hanya kerangka (framework): aturan mainnya sedikit, tapi disiplin menjalankannya yang menentukan hasil.

Definisi Scrum ini penting Anda hafal dengan tepat karena sering muncul salah kaprah bahwa Scrum sama dengan agile secara umum — padahal Scrum adalah satu kerangka kerja spesifik di dalam keluarga agile, dengan aturan main yang cukup jelas. Tiga pilar ini adalah fondasi filosofisnya: transparansi berarti kalau ada anggota tim yang kesulitan atau terlambat, itu harus terlihat oleh seluruh tim, bukan ditutup-tutupi sampai jadi krisis. Inspeksi berarti tim tidak menunggu sampai akhir proyek untuk mengecek hasil kerja, tapi melakukannya secara rutin dalam siklus pendek. Adaptasi adalah konsekuensi logis dari dua pilar sebelumnya — begitu ada masalah terlihat lewat inspeksi, tim harus berani mengubah rencana secepatnya, bukan memaksakan rencana lama yang sudah terbukti tidak sesuai kenyataan pasar atau kemampuan tim.

Tiga Peran dalam Tim Scrum

Tim Scrum sengaja dibuat kecil (idealnya ~10 orang atau kurang) dengan tiga peran yang saling melengkapi, tanpa jabatan "manajer proyek" tradisional:

PRODUCT OWNER

APA YANG DIBANGUN

Menentukan & memprioritaskan fitur yang paling bernilai bagi bisnis & pengguna.

SCRUM MASTER

BAGAIMANA TIM BEKERJA

Menjaga proses Scrum berjalan lancar & menyingkirkan hambatan tim — bukan atasan tim.

DEVELOPMENT TEAM

BAGAIMANA MEMBANGUN

Tim lintas keahlian (desainer, developer, dll.) yang benar-benar mengerjakan produk.

Ketiga peran ini sengaja dirancang agar tidak tumpang tindih, dan kesalahan paling umum tim startup pemula adalah mencampuradukkan ketiganya ke satu orang founder yang kelelahan. Product Owner adalah suara bisnis dan pengguna di dalam tim — dialah yang memutuskan fitur mana yang paling penting dikerjakan lebih dulu, misalnya apakah fitur pembayaran atau fitur notifikasi yang harus selesai duluan. Scrum Master bukan bos yang memerintah tim, justru sebaliknya, perannya melayani tim dengan menyingkirkan hambatan, memfasilitasi rapat, dan menjaga agar aturan main Scrum benar-benar dipatuhi bukan sekadar formalitas. Development Team adalah kumpulan orang dengan keahlian berbeda-beda tapi bekerja sebagai satu kesatuan, tanpa hierarki internal yang kaku, karena mereka bertanggung jawab kolektif atas kualitas hasil kerja. Di startup kecil, satu orang kadang merangkap dua peran, tapi penting Anda paham batasan tanggung jawabnya tetap terpisah secara konseptual.

Bagian 2 dari 3

Artefak & Acara Scrum

Dokumen kerja yang dikelola tim dan ritme rapat yang menjaga siklus sprint tetap disiplin.

Tiga Artefak Scrum

Artefak adalah dokumen kerja hidup yang membuat progres tim transparan dan bisa diinspeksi kapan saja:

PRODUCT BACKLOG

Daftar seluruh fitur/kebutuhan produk, diurutkan berdasarkan prioritas, dikelola Product Owner. Tidak pernah "selesai" sepenuhnya.

SPRINT BACKLOG

Potongan Product Backlog yang dipilih tim untuk dikerjakan dalam satu sprint berjalan.

INCREMENT

Bagian produk yang selesai & siap dipakai di akhir sprint — bukan setengah jadi.

Setiap item di Product Backlog biasanya ditulis sebagai User Story (cerita kebutuhan pengguna) — format ini akan kita latih menulisnya beberapa slide lagi.

Tiga artefak ini adalah "peta kerja" yang selalu bisa dilihat siapa pun di tim tanpa perlu bertanya ke orang lain — inilah wujud nyata prinsip transparansi yang kita bahas sebelumnya. Product Backlog ibarat daftar belanja besar semua hal yang ingin dibangun untuk produk, mulai dari fitur utama sampai perbaikan kecil, dan daftar ini terus tumbuh serta berubah prioritasnya seiring tim belajar dari pasar. Sprint Backlog adalah potongan kecil dari daftar besar itu yang benar-benar disanggupi tim untuk selesai dalam satu sprint, misalnya dua minggu ke depan — begitu sprint dimulai, daftar ini sebisa mungkin tidak diubah-ubah supaya tim fokus. Increment adalah hasil akhirnya, dan syaratnya ketat: harus benar-benar berfungsi dan bisa dipakai, bukan kode setengah jadi yang masih penuh bug, karena itulah inti nilai yang dijanjikan Scrum ke pengguna dan investor tiap sprint.

Ritme Kerja: Empat Acara dalam Satu Sprint

Keempat acara ini adalah satu-satunya rapat wajib dalam Scrum — tujuannya menjaga inspeksi & adaptasi berjalan disiplin tanpa rapat berlebihan.

Perhatikan bahwa keempat acara ini bukan rapat sembarangan, tapi masing-masing punya tujuan spesifik dan durasi yang dijaga ketat. Sprint Planning terjadi di awal setiap sprint, tim bersama Product Owner memutuskan item mana dari Product Backlog yang akan dikerjakan sprint ini. Daily Scrum adalah rapat singkat harian, idealnya hanya lima belas menit berdiri, di mana tiap anggota tim menjawab tiga hal — apa yang sudah dikerjakan kemarin, apa rencana hari ini, dan hambatan apa yang dihadapi. Sprint Review terjadi di akhir sprint, tim mendemonstrasikan increment yang sudah selesai kepada stakeholder, termasuk mungkin investor atau calon pengguna, untuk mendapat umpan balik langsung. Retrospective adalah acara terakhir, khusus untuk tim introspeksi cara kerja mereka sendiri — apa yang berjalan baik, apa yang perlu diperbaiki sebelum sprint berikutnya dimulai lagi, dan siklus ini berputar terus sampai produk benar-benar matang.

Hitung dari Nol #1: Kapasitas Sprint Tim

Kasus: startup Anda punya 4 developer, sprint berlangsung 10 hari kerja (2 minggu), tiap developer punya kapasitas efektif 5 jam/hari untuk coding fokus (sisanya rapat & hal lain). Estimasi tim: 1 story point ≈ 2 jam kerja fokus.

Langkah	Perhitungan	Nilai
Identifikasi	4 developer × 10 hari × 5 jam/hari	—
Total jam kerja fokus tim	4 × 10 × 5 jam	200 jam
Kapasitas teoretis (story point)	200 jam ÷ 2 jam/SP	100 SP
Kapasitas realistis (faktor fokus 70%)	100 SP × 70%	70 SP

Faktor fokus 70% bersifat ilustratif — mengoreksi rencana idealis dengan gangguan nyata (rapat, onboarding, bug tak terduga). Tim baru sebaiknya pakai faktor lebih rendah dulu sampai punya data velocity (kecepatan kerja) historis sendiri.

Latihan ini penting karena kesalahan paling umum tim startup pemula adalah berjanji terlalu banyak pekerjaan dalam satu sprint, lalu gagal memenuhinya dan kehilangan kepercayaan stakeholder. Langkah pertama selalu identifikasi tiga variabel kunci: jumlah anggota tim, panjang sprint dalam hari kerja, dan kapasitas jam fokus harian tiap orang. Langkah kedua, kalikan ketiganya untuk dapat total jam kerja fokus tim selama sprint, dalam kasus ini dua ratus jam. Langkah ketiga, konversi jam itu ke satuan story point memakai rasio estimasi tim, menghasilkan seratus story point sebagai kapasitas teoretis maksimum. Langkah terakhir dan paling penting, terapkan faktor koreksi realistis karena dalam praktiknya tidak semua jam benar-benar terpakai untuk coding murni — ada rapat, gangguan, dan hal tak terduga, sehingga kapasitas sprint yang aman untuk dijanjikan ke Product Owner adalah tujuh puluh story point, bukan seratus.

Coba Sendiri: Hitung Kapasitas Sprint Tim Anda

Ubah jumlah developer, panjang sprint, dan faktor fokus, lalu lihat berapa story point yang aman dijanjikan ke Product Owner.

Menulis Kebutuhan sebagai User Story

Setiap item Product Backlog ditulis dari sudut pandang pengguna, bukan bahasa teknis, memakai format baku:

Langkah	Format	Contoh
1. Siapa	"Sebagai [peran pengguna]..."	Sebagai pemilik warung UMKM...
2. Apa	"...saya ingin [fitur/aksi]..."	...saya ingin menerima notifikasi pesanan baru...
3. Mengapa	"...supaya [nilai/manfaat]."	...supaya tidak melewatkan pesanan pelanggan.
4. Estimasi	Tim beri story point (skala Fibonacci: 1,2,3,5,8...)	Disepakati tim: 3 SP

Format User Story ini sengaja dibuat sederhana supaya Product Owner yang mungkin bukan orang teknis tetap bisa menulisnya dengan jelas, dan tim developer memahami konteks kebutuhan bisnisnya, bukan cuma daftar tugas teknis kering. Langkah pertama menentukan siapa pengguna yang mendapat manfaat — ini penting karena satu fitur bisa berarti berbeda untuk peran berbeda, misalnya pemilik warung versus pelanggan pembeli. Langkah kedua menuliskan aksi atau fitur konkret yang diinginkan, ditulis sesederhana mungkin. Langkah ketiga, bagian yang paling sering dilupakan pemula, menjelaskan alasan atau nilai di baliknya — tanpa ini, tim developer sering membangun fitur secara teknis benar tapi tidak menjawab masalah nyata pengguna. Langkah terakhir, tim memberi estimasi ukuran pekerjaan dalam story point memakai skala Fibonacci — bukan jam pasti, melainkan ukuran relatif kompleksitas, sehingga cerita bernilai tiga story point dianggap kira-kira tiga kali lebih kompleks dari cerita bernilai satu.

Papan Kerja: Melacak Progres Harian

Banyak tim Scrum memvisualisasikan Sprint Backlog memakai papan bergaya Kanban (papan visual asal Jepang, artinya "kartu tanda") supaya progres terlihat sekilas mata:

TO DO

Item Sprint Backlog yang belum dikerjakan. Diurutkan prioritas dari atas.

IN PROGRESS

Sedang dikerjakan seseorang. Idealnya dibatasi WIP limit (batas kerja paralel) supaya tim tidak multitasking berlebihan.

DONE

Selesai & memenuhi Definition of Done tim — bisa didemokan di Sprint Review.

Kartu bergerak dari kiri ke kanan setiap hari — kalau satu kolom "In Progress" menumpuk terlalu banyak kartu tanpa bergerak, itu tanda hambatan (bottleneck) yang wajib dibahas di Daily Scrum.

Papan Kanban ini adalah alat visual paling sederhana namun paling efektif untuk menjaga transparansi progres harian, dan hampir semua tools manajemen proyek modern seperti Trello atau Jira mengadopsi tampilan tiga kolom ini sebagai default. Kolom To Do berisi semua pekerjaan yang sudah disepakati untuk sprint ini tapi belum disentuh, diurutkan supaya yang paling penting ada di paling atas. Kolom In Progress harus dijaga ketat lewat konsep WIP limit, singkatan dari work in progress limit, karena kalau tiap orang mengerjakan lima hal sekaligus, semuanya lambat selesai dan kualitasnya menurun — riset produktivitas tim konsisten menunjukkan fokus pada sedikit hal sekaligus lebih efisien daripada multitasking. Kolom Done punya syarat ketat bernama Definition of Done, kesepakatan tim tentang kapan sesuatu benar-benar dianggap selesai, misalnya sudah diuji dan tidak ada bug kritis, bukan sekadar "kodenya sudah ditulis". Kalau Anda perhatikan satu kolom menumpuk kartu tanpa bergerak berhari-hari, itu sinyal jelas ada masalah yang harus segera dibahas tim, bukan dibiarkan.

Bagian 3 dari 3

Praktik, Tools & Jebakan Umum

Membaca progres sprint, memilih tools yang tepat untuk startup, dan menghindari kesalahan tim pemula.

Hitung dari Nol #2: Membaca Progres Burndown

Kasus: sprint tim Anda punya total 70 story point (hasil Hitung #1), berlangsung 10 hari kerja. Sampai hari ke-6, tim sudah menyelesaikan 42 story point.

Langkah	Perhitungan	Nilai
Identifikasi	Total = 70 SP; selesai hari ke-6 = 42 SP	—
Sisa pekerjaan	70 SP − 42 SP	28 SP
Sisa hari sprint	10 hari − 6 hari	4 hari
Kecepatan dibutuhkan vs ideal	28 SP ÷ 4 hari = 7 SP/hari, vs ideal 70÷10 = 7 SP/hari	Tepat sesuai target

Karena kecepatan yang dibutuhkan (7 SP/hari) sama persis dengan kecepatan rata-rata ideal sprint, grafik burndown tim ini berada tepat di garis target — sinyal sprint sehat, tidak perlu intervensi darurat.

Grafik burndown adalah alat paling umum dipakai Scrum Master untuk memantau kesehatan sprint tanpa harus membaca detail tiap tugas satu per satu. Langkah pertama, seperti biasa, identifikasi angka totalnya — total pekerjaan sprint dan berapa yang sudah selesai sampai hari ini. Langkah kedua, kurangkan untuk tahu sisa pekerjaan, dalam kasus ini dua puluh delapan story point yang belum tersentuh. Langkah ketiga, hitung sisa hari kerja yang tersedia, empat hari dari sepuluh hari total sprint. Langkah terakhir dan paling bermakna, bandingkan kecepatan yang dibutuhkan untuk menghabiskan sisa pekerjaan dengan kecepatan rata-rata ideal sejak awal sprint — kalau angkanya sama atau lebih rendah seperti kasus ini, tim dalam kondisi aman dan tidak perlu intervensi darurat, tapi kalau kecepatan yang dibutuhkan jauh lebih tinggi dari rata-rata ideal, itu tanda tim harus segera membahas hambatan di Daily Scrum berikutnya sebelum sprint gagal total.

Tools Digital untuk Menjalankan Scrum

Startup tidak perlu software mahal untuk mulai menerapkan Scrum — berikut pilihan populer sesuai skala tim:

Tools	Cocok untuk	Kekuatan Utama
Trello	Tim sangat kecil (2–5 orang), pemula	Papan Kanban visual, sangat mudah dipelajari
Notion	Tim yang butuh backlog + dokumentasi jadi satu	Fleksibel, gabung catatan & papan tugas
Jira	Tim lebih besar / produk teknis kompleks	Fitur Scrum lengkap (backlog, sprint, laporan burndown otomatis)
Asana	Tim yang campur proyek Scrum & non-Scrum	Manajemen tugas serbaguna lintas tim

Untuk proyek akhir laboratorium ini, tools bukan yang utama — disiplin menjalankan Sprint Planning, Daily Scrum, Review, dan Retrospective jauh lebih menentukan keberhasilan daripada software yang dipakai.

Pilihan tools ini sengaja saya urutkan dari yang paling sederhana ke paling lengkap supaya Anda bisa memilih sesuai skala dan kebutuhan tim proyek akhir laboratorium. Trello sangat cocok untuk tim pemula karena tampilannya persis seperti papan Kanban yang kita bahas tadi, tinggal drag-and-drop kartu, dan versi gratisnya sudah lebih dari cukup untuk tim kecil. Notion belakangan populer di kalangan startup karena bisa menggabungkan dokumentasi produk, catatan rapat, dan papan tugas dalam satu tempat, cocok kalau tim Anda ingin semuanya rapi dalam satu ruang kerja. Jira adalah standar industri untuk tim yang lebih besar dan produk teknis kompleks, punya laporan burndown otomatis persis seperti yang kita hitung manual tadi, tapi kurvanya sedikit lebih curam untuk pemula. Yang paling penting saya tekankan, tools hanyalah alat bantu — tim yang disiplin menjalankan ritme sprint dengan Trello gratis bisa jauh lebih sukses daripada tim yang punya Jira mahal tapi tidak pernah benar-benar melakukan Daily Scrum atau Retrospective.

Studi Kasus: Scrum di Tim Produk Startup

Praktik kerja Scrum & Kanban umum dipakai tim produk startup teknologi di Indonesia (mis. tim engineering di platform e-commerce & ride-hailing besar) untuk merilis fitur baru secara bertahap dan cepat.

POLA UMUM

Tim kecil lintas fungsi (produk, desain, engineering) bekerja dalam sprint 1–2 minggu, merilis fitur bertahap alih-alih menunggu produk "sempurna".

MANFAAT DIRASAKAN

Umpan balik pengguna didapat lebih cepat, kesalahan asumsi ketahuan sebelum investasi waktu besar-besaran.

Detail praktik tiap perusahaan bervariasi & tidak selalu dipublikasikan resmi — anggap ini pola umum industri, bukan klaim spesifik satu perusahaan tertentu.

Studi kasus ini sengaja saya sampaikan sebagai pola umum industri, bukan klaim rinci satu perusahaan tertentu, karena detail cara kerja internal perusahaan jarang dipublikasikan resmi dan sering berubah seiring waktu. Yang bisa kita pelajari dengan yakin adalah polanya: hampir semua startup teknologi skala menengah sampai besar di Indonesia, termasuk platform e-commerce dan ride-hailing yang mungkin ada aplikasinya di ponsel Anda, mengorganisir tim engineering mereka dalam kelompok-kelompok kecil lintas fungsi yang bekerja dengan siklus pendek mirip sprint Scrum. Manfaat yang konsisten dirasakan industri adalah kecepatan mendapat umpan balik nyata dari pengguna, jauh lebih cepat dibanding menunggu produk sempurna dulu baru dirilis ala waterfall. Untuk proyek akhir laboratorium Anda, pelajaran praktisnya adalah: jangan menunggu aplikasi Anda sempurna seratus persen sebelum diuji ke calon pengguna UMKM atau target pasar Anda — rilis versi kecil yang berfungsi, lalu belajar dan perbaiki di sprint berikutnya.

Jebakan Umum Tim Scrum Pemula

Menerapkan Scrum "di atas kertas" mudah — menjalankannya dengan disiplin yang menantang. Waspadai tiga jebakan ini:

JEBAKAN 1

RETRO DILEWATI

Tim buru-buru mulai sprint baru tanpa evaluasi — kesalahan yang sama terus berulang.

JEBAKAN 2

SCOPE CREEP

Fitur baru dipaksa masuk di tengah sprint berjalan — merusak fokus & estimasi tim.

JEBAKAN 3

DAILY JADI LAPORAN

Daily Scrum berubah jadi laporan status ke "atasan" — bukan koordinasi antar rekan tim.

Ketiganya punya akar sama: disiplin proses dikorbankan demi kecepatan sesaat — padahal justru disiplin itulah yang membuat Scrum lebih cepat dalam jangka panjang.

Ketiga jebakan ini sangat sering saya lihat pada tim mahasiswa yang baru pertama kali mencoba Scrum untuk proyek kelompok, jadi penting Anda kenali sejak awal. Jebakan pertama, melewatkan Retrospective, biasanya terjadi karena tim merasa "sudah tahu apa yang salah" jadi malas membahasnya secara formal — padahal justru forum inilah yang memastikan pembelajaran itu benar-benar disepakati dan ditindaklanjuti bersama, bukan cuma di kepala satu orang. Jebakan kedua, scope creep yang artinya penambahan cakupan pekerjaan tanpa terkendali, terjadi ketika ada permintaan fitur baru mendadak di tengah sprint dan tim langsung mengiyakan tanpa mempertimbangkan dampaknya ke komitmen yang sudah disepakati di Sprint Planning. Jebakan ketiga terjadi ketika Daily Scrum kehilangan rohnya sebagai forum koordinasi antar rekan setara, dan berubah jadi sesi melapor ke satu orang yang dianggap atasan, sehingga anggota tim jadi defensif alih-alih terbuka soal hambatan yang mereka hadapi. Kalau Anda menjaga disiplin di tiga titik ini pada proyek akhir laboratorium nanti, tim Anda akan jauh lebih siap dibanding kebanyakan tim mahasiswa lain.

Latihan: Rancang Sprint Pertama Anda

Berperanlah sebagai tim Scrum untuk startup fiktif: aplikasi antar-jemput laundry untuk mahasiswa kos.

DISKUSIKAN DALAM KELOMPOK (10 MENIT)

Tentukan 4–5 User Story awal (format: Sebagai... saya ingin... supaya...).
Beri estimasi story point tiap User Story (skala Fibonacci: 1, 2, 3, 5, 8).
Tentukan siapa berperan Product Owner & Scrum Master di kelompok Anda.
Sepakati satu Definition of Done sederhana untuk sprint pertama ini.

Tiap kelompok presentasi 1 menit — fokus pada 2 User Story prioritas tertinggi & alasannya.

Latihan ini adalah simulasi paling mendekati apa yang akan Anda lakukan sungguhan saat memulai proyek akhir laboratorium minggu depan, jadi mari kita manfaatkan sepuluh menit ini dengan serius. Dorong tiap kelompok benar-benar menulis User Story dengan format lengkap yang sudah kita latih, bukan sekadar daftar fitur teknis kering tanpa konteks "mengapa"-nya. Perhatikan estimasi story point yang mereka berikan — biasanya kelompok pemula cenderung meremehkan kompleksitas, jadi dorong mereka berdiskusi kenapa satu cerita dinilai lebih sulit dari yang lain, bukan asal menebak angka. Poin keempat soal Definition of Done sengaja saya masukkan supaya tiap kelompok berlatih menyepakati standar kualitas bersama sejak awal, karena ini sering diabaikan tim pemula dan berujung perdebatan "sudah selesai belum" yang seharusnya bisa dihindari.

Rangkuman & Menuju Pertemuan Berikutnya

Elemen	Inti	Contoh Penerapan
3 Peran	Product Owner, Scrum Master, Development Team	Tugas & tanggung jawab terpisah jelas
3 Artefak	Product Backlog, Sprint Backlog, Increment	Dokumen kerja transparan & hidup
4 Acara	Planning, Daily Scrum, Review, Retrospective	Ritme inspeksi & adaptasi rutin
Ukuran progres	Story point, velocity, burndown	Kapasitas sprint & deteksi dini keterlambatan

MINGGU DEPAN

UI/UX & Prototype — menerjemahkan User Story hari ini menjadi rancangan antarmuka nyata.

TUGAS

Finalisasi 4–5 User Story kelompok Anda dari latihan tadi, lengkap estimasi story point. Bawa ke kelas berikutnya sebagai bekal Sprint Planning pertama proyek akhir.

Sebagai penutup, mari kita rangkum lewat tabel di layar — tiga peran, tiga artefak, empat acara, dan cara mengukur progres lewat story point serta burndown, dan kerangka ini akan terus relevan sepanjang sisa semester karena proyek akhir laboratorium Anda akan dijalankan persis dengan pola ini. Kita sudah bergerak dari memahami mengapa Scrum lahir menggantikan waterfall, ke mekanik detail peran dan artefaknya, sampai berlatih menghitung kapasitas sprint dan membaca grafik burndown seperti product manager sungguhan. Minggu depan kita lanjut ke UI/UX dan Prototype, di mana User Story yang Anda tulis hari ini akan mulai diterjemahkan menjadi rancangan tampilan aplikasi yang bisa dilihat dan dicoba calon pengguna. Untuk tugas, saya minta Anda menyelesaikan dan merapikan empat sampai lima User Story kelompok dari latihan tadi lengkap dengan estimasi story point-nya, karena inilah bahan baku yang akan langsung Anda pakai untuk Sprint Planning pertama proyek akhir laboratorium.