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 bagian-bagian yang lebih kecil atau ditahan.
Tim scrum memiliki beberapa skala titik upaya yang mereka miliki [LINK]tetapi mereka semua memiliki satu kesamaan: mereka bekerja paling baik ketika diterapkan pada cerita yang paling sederhana.
Pertimbangkan rutinitas pagi Anda. Jika ditanya seberapa rumit persiapan untuk bekerja, bagaimana Anda memberikan upaya? Berpikir samar-samar, Anda mungkin melihatnya seperti ini: merapikan tempat tidur, 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 Panaskan kompor Masak telur dan bacon di wajan Mulai kopi …dll.
Berpakaian…
Kenakan pakaian dalam. Kenakan kaus kaki. Kenakan celana. …dll.
Tugas-tugas kecil yang mudah dipahami ini tidak meninggalkan banyak imajinasi, dan Anda dapat dengan percaya diri menetapkan 1 atau 2 poin untuk masing-masing tugas. Hampir mudah untuk menunjuk sebagai tim, dan kemudian menyelesaikannya sebagai pengembang.
Cerita yang lebih besar menghasilkan penunjukan upaya yang tidak akurat, yang dapat menyebabkan masalah serius selama perencanaan dan sepanjang sprint. Apakah cerita 20 poin itu benar-benar 29? Itu 40 sebenarnya 60? Sayangnya, tim Anda mungkin tidak akan mengetahuinya sampai sprint hampir selesai.
Selain ukuran, seiring bertambahnya kompleksitas, begitu pula ketidakakuratan perkiraan cerita. Terlepas dari niat terbaik kami, manusia tidak selalu berpikir secara linier, jadi memecah cerita menjadi bagian-bagian yang lebih sederhana dapat secara serius meningkatkan kepastian pengembang di seluruh sprint backlog.
Jadi, Apa yang Harus Dilakukan Scrum Master?
Pertama, penting untuk diingat bahwa setiap tim berbeda. Sama seperti beberapa orang bertangan raksasa akan menyukai phablet 7 inci, beberapa tim dapat menangani cerita besar. Namun, sebagian besar tim akan merasa lebih mudah untuk mencapai keseimbangan antara epik besar dan cerita kecil.
20-an, 40-an dan 100-an memiliki tempatnya – hanya saja tidak dalam sprint Anda. Anda biasanya akan melihat angka-angka tersebut saat mengarahkan backlog produk di awal proyek baru, atau saat menambahkan item baru ke backlog sepanjang siklus pengembangan Anda. Menetapkan upaya besar untuk cerita yang kompleks dapat bermanfaat bagi pemilik produk yang perlu memprioritaskan epos berdasarkan nilai dan usaha. Hal ini dapat mengakibatkan cerita tertentu terdorong ke belakang, tetapi ketidakjelasan estimasi dapat membantu PO menentukan nilai cerita.
Namun, ketika cerita naik ke tumpukan simpanan, 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 berbicara tentang bagaimana hal itu dapat disempurnakan.
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. Lakukan putaran hari ini untuk melihat bagaimana hal itu dapat bermanfaat bagi sprint Anda berikutnya.
Coba gratis
Kredit Foto
