Scrum: Siapa yang Menciptakan Item Backlog Produk atau Cerita Pengguna?

Pertanyaan ini lebih kompleks daripada yang tampak pada awalnya. Pertama, Anda dapat mengatakan bahwa Backlog Produkitem dapat mencakup kasus penggunaan, epik, cerita pengguna, bahkan bug, atau tugas penelitian dengan batas waktu dalam backlog produk.
Dalam definisi paling sederhana, ScrumBacklog Produk Scrum hanyalah daftar semua Item Backlog Produk (PBIs) yang perlu diselesaikan dalam proyek. Ini menggantikan artefak spesifikasi kebutuhan tradisional artefak. PBIs mencerminkan kebutuhan pelanggan atau pemangku kepentingan. Pendekatan umum untuk menangkap kebutuhan pengguna akhir adalah menulis PBIs dalam bentuk cerita pengguna.

Siapa yang Bertanggung Jawab atas Pemeliharaan Backlog Produk?

Pemilik Produk (PO) Pemilik Produk (PO)“memiliki” backlog produk atas nama pemangku kepentingan dan secara utama bertanggung jawab atas pembuatannya. PO tidak perlu membuat backlog secara pribadi—dia dapat menyerahkan kepada tim pengembangan dan/atau Master Scrumuntuk membantu mendefinisikan dan memperkirakan item-item backlog. PO bertanggung jawab atas pembuatan dan pemeliharaan backlog produk. Oleh karena itu, PO juga mengawasi proses penyempurnaan backlogproses.
Backlog produk sesuai dengan peta jalan proyek Anda—rencana yang ingin tim kirimkan. Setelah tim menentukannya, mereka menentukan prioritas fitur dan kebutuhan apa yang harus dibangun. Backlog produk juga berfungsi sebagai repositori yang berisi semua informasi yang dibutuhkan tim untuk melacak dan berbagi.

Apakah Item Backlog Produk sama dengan Cerita Pengguna?

Seperti disebutkan, PBIs mencerminkan kebutuhan pelanggan atau pemangku kepentingan. Cara umum untuk menangkap kebutuhan pengguna akhir adalah menulis PBIs dalam bentuk cerita pengguna. Namun, PBIs juga dapat mencakup kasus penggunaan, epik, cerita pengguna, bug, atau tugas penelitian dengan batas waktu dalam backlog produk. Pada kenyataannya, tidak semua item dalam backlog produk memiliki tingkat detail yang sama, seperti yang ditunjukkan pada gambar di bawah ini:
Detailed Product Backlog
Backlog Produk yang Rinci
PBIs yang rencananya akan dikerjakan segera sebaiknya berada di dekat bagian atas backlog, lebih kecil ukurannya, dan sangat rinci agar dapat dikerjakan dalam waktu singkat Sprint. PBIs yang tidak akan kita kerjakan dalam waktu dekat sebaiknya berada di bagian bawah daftar prioritas—lebih besar, kurang rinci. Tidak masalah; kita tidak berniat mengerjakan item-item ini dalam waktu dekat.
Ketika kita semakin dekat untuk mengerjakan PBIs yang lebih besar, seperti epik, kita memecahnya menjadi serangkaian cerita kecil yang siap untuk sprint. Ini harus dilakukan secara tepat waktu. Jika kita memperhalus terlalu dini, kita mungkin membuang waktu untuk mengatur detail yang tidak pernah diimplementasikan. Jika kita menunggu terlalu lama, kita akan menghambat PBIs untuk masuk ke dalam sprint dan memperlambat tim. Kita perlu menemukan keseimbangan yang tepat pada waktu yang tepat.
Agile Prioritized Product Backlog
Daftar Prioritas Produk Berbasis Agile

Siapa yang Bertanggung Jawab atas Penyempurnaan PBIs?

Product Owner (PO), yang “memiliki” daftar prioritas produk atas nama pemangku kepentingan, secara utama bertanggung jawab atas pembuatan dan pemeliharaannya. PO tidak perlu membuat setiap item daftar prioritas secara pribadi—ia dapat melibatkan tim pengembangan dan/atau Scrum Master untuk membantu mendefinisikan dan memperkirakan item. PO mengawasi seluruh proses penyempurnaan daftar prioritas.
Dengan demikian, untuk menjawab pertanyaan: Product Owner memiliki daftar prioritas produk, tetapi tidak perlu membuat setiap item daftar prioritas. Secara umum, Product Owner dapat membuat PBIs besar berdasarkan kebutuhan tingkat tinggi atau tujuan pengguna, lalu menyerahkan kepada tim untuk membantu memecah item besar tersebut menjadi cerita pengguna. Cerita-cerita kecil ini—sesuai untuk bagian atas daftar prioritas dan memenuhi kriteria “Siap” (biasanya di bawah Definisi Siap)—kemudian dipindahkan ke dalam Daftar Prioritas Sprint.

Leave a Reply