Apa Itu Sprint Dalam Scrum dan Penerapan Sprint Pada Suatu Pengembangan Software
Sprint merupakan kumpulan aktifitas atau kegiatan yang dilakukan oleh Scrum Tim dalam satu periode untuk menambahkan/menyelesaikan suatu bagian dari produk. Satu periode Sprint dilakukan sekitar dua minggu ataupun empat minggu (satu bulan), dan dapat juga dilakukan satu minggu sesuai kebutuhan. Diakhir Sprint, diharapkan produk dapat digunakan dan berpotensi untuk release. Sehingga, Client dapat langsung memberikan feedback terhadap progress yang telah diselesaikan dan menjadi masukan untuk proses Sprint berikutnya. Proses untuk mendapatkan feedback dan pengerjaan secepatnya adalah tujuan dari Sprint. Proses Sprint terus diulang sampai keinginan Client terpenuhi.
Terdapat tiga aktifitas utama yang dilakukan dalam sebuah Sprint, yaitu:
- Sprint Planning
- Sprint Development
- Sprint Retro & Review
Sebelum membahas aktifitas Sprint, sebaiknya kita membahas apa saja Role dalam Scrum Tim. Ada tiga role utama, yaitu:
- Product Owner (PO), pemilik project (bukan Client). PO akan melakukan diskusi dengan Stakeholders (cth: Client), dan hasil kesepakatan yang ada akan di sharing ke Scrum Tim untuk dikerjakan.
- Development Tim (Tech Tim), Developer dan Designer.
- Scrum Master, penengah antara PO dan DT, serta memberikan fasilitas kepada Tech Tim agar dapat menyelesaikan Sprint dengan baik dan cepat.
Sprint Planning
Inti dari sprint planning, yaaa plan, merencanakan sesuatu. Pertanyaannya adalah apa yang direncakan, oleh siapa untuk apa??
Yang merencakan Sprint Planning adalah PO dan Tech Tim yang jadwalnya diatur oleh Scrum Master. Sprint planning dimulai dari PO yang menulis fitur-fitur product yang diinginkan di dalam Product Backlog dan mengurutkannya berdasarkan fitur yang paling penting dan ingin dikerjakan segera. Product Backlog yang ada akan didiskusikan dengan Tech Tim. Hal ini dilakukan agar Tech Tim dapat membayangkan fungsionalitas produk dan hal-hal apa saja yang harus mereka lakukan, serta menanggapi jika terdapat kesulitan-kesulitan yang akan terjadi kedepannya.
Setelah diskusi, Tech Tim akan memilih dan menentukan seberapa banyak Product Backlog yang dapat diselesaikan dan akan COMMIT (100% berkomitmen) menyelesaikannya selama satu Sprint kedepan. Product Backlog yang dipilih untuk dikerjakan dalam Sprint tersebut disebut Sprint Backlog. Dalam hal ini, Tech Tim leluasa mengambil pekerjaan semampu dirinya untuk diselesaikan. “Kita sendiri yang memilih seberapa banyak pekerjaan yang mampu kita selesaikan dan COMMIT untuk menyelesaikannya”. Pertanyaannya adalah, bagaimana jika tidak selesai?? “we should be ashamed of ourselves”.
Setelah mendapatkan Sprint Backlog yang akan diselesaikan, PO dan Tech Tim menentukan Sprint Goal. Mengapa Sprint Goal diperlukan padahal kita sudah memiliki rencana-rencana yang tertulis di Sprint Backlog?? Seperti yang kita ketahui sulitnya mengembangkan suatu produk, dan tentunya rencana yang direncanakan tidak 100% akan berjalan lancar, dan akan terjadi kendala yang tidak direncanakan ditengah-tengah Sprint. Jika hal ini terjadi, maka ada kemungkinan lingkup backlog akan dinegosiasikan ulang. Disinilah peran Sprint Goal agar hasil yang dinegosiasikan tersebut tidak melenceng dengan tujuan awal (Sprint Goal).
Tambahan: Umumnya Product Backlog, Sprint Backlog beserta Sub Task yang ada dibuat pada suatu Kanban Board, sehingga Tech Tim dapat melihat “Big Picture” Sprint secara kesuluhan sudah sampai mana proses Sprint yang telah dilakukan. Minimum Kanban Board minimal terdiri dari enam bagian, yaitu: 1) Back Log, 2) Sub Task, 3) Reject, 4) On Progress, 5) Testing, and 6) Done.
Kesimpulan Sprint Planning:
- Input: Product Backlog yang berurutan dari PO
- Process: Review dan pemilihan Product Backlog yang akan dikerjakan
- Output: Sprint Backlog dimana seluruh Tech Tim COMMIT untuk menyelesaikannya diakhir Sprint
Sprint Development
Terdapat dua hal penting yang dilakukan dalam aktifitas ini, yang pertama adalah proses development itu sendiri dan yang kedua adalah Daily Scrum. Dalam proses Development, biasanya lead dari Tech Tim ataupun masing-masing anggota akan membuat suatu Sub Task dari Sprint Backlog. Sub Task tersebut merupakan suatu pekerjaan kecil agar Sprint Backlog dapat diselesaikan. Kemudian anggota Tim akan memilih Sub Task tersebut untuk dikerjakan dan memindahkannya kebagian On Progress pada Kanban Board. Ketika seseorang mengambil Sub Task tersebut untuk ia kerjakan, maka ia telah COMMIT akan menyelesaikan Sub Task tersebut. Dikarenakan berpindahnya Sub Task tersebut ke On Progress, maka anggota Tim/rekan yang lain dapat mengetahui bahwasanya Sub Task tersebut sedang dikerjakan dan anggota tersebut dapat mengerjakan Sub Task yang lain.
Contoh: “Sub Task : I) Create DB User. II) Integrate DB User”. Dalam hal ini A akan mengambil Sub Task I di Kanban Board, memindahkannya ke On Progress, dan mengerjakan Task Tersebut. Ketika B ingin mengerjakan sesuatu, maka ia melihat Sub Task I telah dikerjakan, maka ia akan mengambil Sub Task II, memindahkannya ke On Progress dan mengerjakannya. Setelah selesai, A dan B memindahkan Sub Task mereka ke Testing, dst. Sebaiknya hal ini dibahas lengkap pada Artikel lainnya..
Selanjutnya adalah Daily Scrum, Daily Scrum merupakan suatu aktifitas yang dilakukan oleh seluruh Tech Tim tiap harinya dimana masing-masing anggota akan menyampaikan tiga hal, yaitu: 1) Apa yang telah saya selesaikan, 2) Apa yang akan saya selesaikan hari ini (COMMIT), dan 3) Kendala apa yang saya hadapi. Daily Scrum dilakukan maksimal 15 menit, dan biasanya didepan Kanban Board. Hal ini sangat efektif dilakukan untuk menghindari sistem Kebut Semalam dikarenakan progress project terus bertumbuh dan dapat dipantau tiap harinya.
Seperti yang tertulis pada point ke tiga, tiap orang dapat menyampaikan kendala yang ia hadapi dan kendala tersebut dapat diselesaikan bersama. Selain ketiga hal tersebut, kita dapat juga mengajukan pertemuan tambahan dengan dengan rekan kita untuk membahas pekerjaan yang ada secara spesifik. Sehingga kita dan rekan kita dapat meluangkan waktu kedepannya yang telah disepakati bersama saat Daily Scrum.
Kesimpulan:
- Input: Sprint Backlog dimana seluruh Tech Tim COMMIT untuk menyelesaikannya diakhir Sprint
- Process: Report harian dan pengerjaan dari Sprint Backlog yang dapat berupa proses design, development, testing and closing
- Output: Penambahan fitur pada produk yang dapat didemonstrasikan
Sprint Review dan Sprint Retro
Sprint Review dan Sprint Retro merupkan kegiatan yang bertujuan untuk mendapatkan feedback dan melakukan continuous improvement pada suatu produk dan Scrum Tim. Continuous improvement inilah salah satu hal mengapa Scrum Sprint banyak digunakan saat ini.
Sprint Review merupakan kegiatan demonstrasi produk yang telah diselesaikan selama Sprint kepada Client. Sprint Review bertujuan untuk mendapatkan masukan langsung dari Client terhadap produk tersebut dan Tech Tim dapat mengetahui apakah yang telah dikerjakan sesuai keinginan Client atau tidak. Selain itu disisi PO dapat mengetahui masukan yang ada dan menambahkan hal tersebut di Sprint selanjutnya.
Sprint Retrospective atau Retro adalah proses penutupan Sprint. Dalam prosesnya seluruh Scrum Tim mengevaluasi bagaimana proses Sprint sebelumnya, apakah seluruh Task dapat diselesaikan dengan baik dan benar, kendala-kendala apa saja yang terjadi, dsb. Kemudian seluruh Scrum Tim mendiskusikan hal-hal apa saja yang dapat dilakukan agar proses Sprint kedepannya lebih baik. Proses ini wajib dihadiri oleh Tech Tim, dikondisikan oleh Scrum Master, dan untuk PO optional.
Kesimpulan:
- Output: Penambahan fitur pada produk yang dapat didemonstrasikan
- Process: Demonstrasi produk untuk mendapatkan masukan product dan evaluasi tim
- Output: Feedback dari suatu produk dan evaluasi yang dapat dilakukan agar Sprint kedepannya lebih baik
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Indonesian.pdf
