Kerjaan buat Sprint depan udah ready lum?
Kata “kerjaan” di sini biasanya merujuk pada User Story atau Use Case sebagai representasi fitur atau fungsionalitas dalam Product Backlog. Coba kamu tanya pertanyaan seperti ini ke Product Owner atau Product Manager kamu. Kemudian perhatikan jawabannya. Pertanyaan ini akan menimbulkan pertanyaan lanjutan, “Seperti apa sih User Story yang ready itu?”
Dari pertanyaan awal dan lanjutan ini, coba lihat apakah Product Owner kamu memiliki definisi yang ajek tentang apa itu “ready” atau siap dari sebuah rencana kerjaan. Jika kamu adalah seorang Product Owner, kedua pertanyaan tersebut bagus untuk ditanyakan ke diri sendiri hehe.
Jadi apa itu sebenarnya kerjaan yang “ready” untuk Sprint?
Definition of Ready
Sekumpulan kondisi yang perlu dipenuhi agar kerjaan pengembangan dikatakan siap disebut dengan Definition of Ready (DoR). DoR ini mungkin seperti checklist kamu saat nyiapin keberangkatan liburan. Bawa uang sekian, tiket kereta, id card, alat mandi, juga botol minum. Oiya, tidak lupa bawa snack. Saat checklist kamu sudah terisi penuh, kamu merasa siap unuk berangkat.
Siapa yang mendefinisikannya? Tim kamu. Sebaiknya kamu bersama tim mendefinisikan kapan suatu User Story disebut ready untuk dibawa ke Sprint.
Apakah saat ada mockup? Saat ada business value pada User Story? Apa saat ada deskripsi singkat tentang User Story? Mana pun yang kamu pilih, buat checklist-nya.
Di bawah ini adalah sebuah contoh DoR suatu tim.
- Ada mockup
- Ada flow diagram atau navigation diagram
Yak, sebenarnya itulah DoR yang didefinisikan di tim saya saat ini.
DoR dalam Praktik Sehari-hari
Untuk menyatakan suatu user story itu ready, saya saat ini memiliki dua poin di atas, yaitu tersedia mockup dan diagram.
Wireframe atau mockup adalah hal yang seringkali ditanyakan developer. Mana mockup-nya? Gimana tampilannya? Wireframe atau mockup memberikan gambaran ke Development Team untuk berdiskusi tentang interaksi aplikasi dan untuk mengestimasi cakupan kerjaan.
Kalau wireframe atau mockup belum tersedia, Sprint terasa kurang lengkap, terasa kurang siap. Estimasi kerjaan jadi lebih sulit. Oleh karenanya, buat saya wireframe atau mockup menjadi prioritas.
Seringkali wireframe atau mockup saja tidak cukup. Logika di balik tampilan tidak tergambar di aplikasi. Oleh karenanya, saya memerlukan diagram untuk menjelaskan alur atau logika.
Misalnya saya mau menjelaskan alur registrasi pengguna melalui email yang nantinya perlu persetujuan admin dan verifikasi email. Lumayan sulit menjelaskan hal seperti hanya mengandalkan mockup. Lebih mudah jika saya sudah menyiapkan diagram tentangnya kemudian menjelaskannya.
Diagram seperti apa yang sebaiknya digunakan? Jawabannya sebenarnya menyesuaikan kebutuhan pengembangan kamu. Navigation diagram biasa saya gunakan untuk menggambarkan alur halaman pada aplikasi. Untuk menggambarkan proses yang njelimet, saya menggunakan BPMN atau Business Process Model and Notation (BPMN ini keren. Saya masih mempelajarinya).
Sumber: https://www.businessprocessincubator.com/content/order-processing/
Seiring bertumbuhnya tim dan produk, Definition of Ready yang kamu miliki mungkin ikut bertumbuh. Awalnya hanya dua poin, nanti mungkin menjadi tiga atau bahkan empat poin. Jika kamu saat ini belum memiliki DoR, ini saat yang bagus untuk mendefinisikannya meski hanya satu poin. Nanti perlahan-lahan kita dapat tambahkan poin-poin yang menggambarkan kesiapan kerjaan pengembangan kita.
Kamu sudah punya Definition of Ready di tim kamu? Share yuk. Akan seru bisa mendiskusikannya bersama-sama.
***
Yuk pelajari Scrum secara lengkap dan mudah di online course “Belajar Scrum: Membangun Produk secara Efektif dengan Scrum”
