Nilai Membatasi Upaya Maksimum pada Cerita

Sama seperti smartphone modern, beberapa cerita pengguna terlalu besar untuk kebaikan mereka sendiri – dan kebaikan tim pengembangan Anda. Faktanya, banyak tim membatasi ukuran maksimum untuk cerita pengguna yang ditarik ke dalam sprint. Apa pun yang terlalu besar akan dipecah menjadi potongan-potongan kecil atau ditahan.

Tim scrum memiliki beberapa skala poin usaha yang mereka miliki [LINK], tetapi semuanya memiliki satu kesamaan: keduanya bekerja paling baik jika diterapkan pada cerita yang sesederhana mungkin.

Pertimbangkan rutinitas pagi Anda. Jika ditanya seberapa rumit bersiap-siap untuk bekerja, bagaimana Anda akan memberikan upaya? Berpikir samar-samar, Anda mungkin melihatnya seperti ini: membereskan tempat tidur, makan sarapan, mandi, menyikat gigi, berpakaian, dan keluar dari pintu. Itu mungkin terlihat seperti petualangan 20 poin.

Tetapi bagaimana jika pagi itu dipecah menjadi beberapa tindakan terpisah? Pagi Anda sekarang mungkin terlihat seperti:

Makan sarapan…

Keluarkan telur, bacon, dan susu dari lemari es. Kompor panas. Masak telur dan daging dalam wajan. Mulai kopi… dll.

Berpakaian…

Kenakan pakaian dalam. Kenakan kaus kaki. Pakai celana. … Dll.

Tugas-tugas kecil dan mudah dipahami ini tidak meninggalkan banyak imajinasi, dan Anda dapat dengan percaya diri memberikan 1 atau 2 poin untuk masing-masingnya. Hampir tidak perlu lagi menunjuk sebagai sebuah tim, dan kemudian menyelesaikannya sebagai pengembang.

Cerita yang lebih besar menghasilkan upaya menunjuk yang tidak akurat, yang dapat menyebabkan masalah serius selama perencanaan dan sepanjang sprint. Apakah cerita 20 poin itu benar-benar 29? 40 itu sebenarnya 60? Sayangnya, tim Anda mungkin tidak akan mengetahuinya sampai sprint hampir selesai.

Selain ukuran, seiring dengan pertumbuhan kompleksitas, ketidakakuratan perkiraan cerita juga meningkat. Terlepas dari niat terbaik kami, manusia tidak selalu berpikir linier, jadi membagi cerita menjadi bagian-bagian yang lebih sederhana dapat secara serius meningkatkan kepastian pengembang di seluruh sprint backlog.

Jadi, Apa yang Harus Dilakukan Master Scrum?
Pertama, penting untuk diingat bahwa setiap tim berbeda. Sama seperti beberapa orang bertangan raksasa yang menyukai phablet 7 inci, beberapa tim dapat menangani cerita besar. Namun, sebagian besar tim akan lebih mudah menemukan keseimbangan antara epos besar dan cerita kecil.

Usia 20-an, 40-an, dan 100-an ada tempatnya – tidak dalam sprint Anda. Anda biasanya akan melihat angka-angka tersebut saat menunjukkan product backlog di awal proyek baru, atau saat menambahkan item baru ke backlog selama siklus pengembangan Anda. Menugaskan upaya besar untuk cerita kompleks dapat bermanfaat bagi pemilik produk yang perlu memprioritaskan epos berdasarkan nilai dan upaya. Ini dapat mengakibatkan cerita tertentu didorong ke backlog, tetapi ketidakjelasan estimasi dapat membantu PO menentukan nilai cerita.

Namun, saat cerita naik ke backlog, inilah saatnya untuk serius memecahnya, menerapkan kriteria penerimaan yang lebih halus dan perkiraan yang lebih akurat. Setelah beberapa sprint bersama, tim Anda harus dapat menentukan ukuran cerita maksimum, bersama dengan ambang peringatan yang memicu diskusi tim. Bawalah cerita yang lebih besar, tetapi bersiaplah untuk membicarakan tentang bagaimana hal itu dapat diperhalus.

Butuh alat yang bagus untuk membantu proses perencanaan Anda? Planning Poker® adalah cara yang terbukti bagi tim untuk mengukur upaya mereka dengan tepat, meningkatkan kolaborasi dan diskusi selama perencanaan sprint. Cobalah hari ini untuk melihat bagaimana manfaatnya pada sprint berikutnya.

Coba gratis

Kredit Foto