Apakah ada cara standar untuk mengetahui kapan harus berhenti menulis cerita pengguna, dan jika demikian, apa dasar untuk ini, dan bagaimana itu berlaku untuk sprint masa depan?
Secara pribadi saya tidak tahu metode standar. Ini benar-benar bermuara pada kombinasi metodologi Anda, dan harapan pelanggan Anda.
Saya telah menemukan bahwa lebih baik memulai pengkodean segera setelah Anda memiliki cerita "cukup" dari pelanggan Anda untuk memulai. Seperti yang dikatakan orang lain, ini bisa untuk satu iterasi tunggal, namun bisa untuk lebih banyak. Ukuran Anda yang cukup harus dipandu oleh seberapa sering Anda berniat untuk merilis kode kerja kepada pelanggan Anda, dan bukannya pelanggan Anda memberi Anda dan daftar cerita yang tak ada habisnya (banyak di antaranya mungkin tidak akan pernah selesai, atau mungkin berubah, atau mungkin tidak membuat tenggat waktu rilis utama Anda), lebih baik untuk meminta pelanggan Anda untuk 3-5 fitur pertama yang paling penting dan prioritas tertinggi. Ketika itu dilakukan dan dirilis ke pelanggan Anda, Anda mengumpulkan 3-5 fitur paling penting berikutnya dan seterusnya. Minta lebih atau kurang tergantung pada berapa lama iterasi Anda akan terjadi.
Pelanggan atau kontrak atau tenggat waktu Anda mungkin dapat memandu Anda kapan harus benar-benar berhenti meminta cerita, namun sementara itu, Anda telah meminta cerita dan berhenti sesering yang sudah Anda lakukan iterasi. Ketika dengan persetujuan Anda dan pelanggan merasa produk itu cukup lengkap, Anda kemudian dapat memutuskan apa yang harus dilakukan dengan cerita sisa yang belum diberikan pelanggan kepada Anda.
Keuntungan utama dari pendekatan ini adalah bahwa Anda pada akhirnya memberikan nilai terbesar kepada pelanggan di muka, dan seiring perkembangan proyek dan waktu berlalu, jumlah nilai yang Anda berikan kepada pelanggan berkurang ke titik di mana pelanggan dapat membuat keputusan tentang "20% fitur terakhir" yang mungkin mereka harapkan yang mungkin tidak pernah benar-benar digunakan. Ini juga menghemat waktu yang terbuang untuk hal-hal sepele dan prioritas rendah, menempatkan tanggung jawab (dan tekanan) dari memprioritaskan dan menjadwalkan iterasi kembali pada pelanggan, dan semua hanya didasarkan pada kebutuhan pelanggan. Namun itu tidak berarti Anda tidak harus memberikan panduan kepada pelanggan untuk menghindari kemacetan penjadwalan yang sulit yang mungkin terlihat saat Anda berbicara persyaratan dengan pelanggan.
Bacalah Pengembangan Perangkat Lunak Ramping Poppendeicks jika Anda menginginkan deskripsi yang lebih rinci tentang pendekatan ini dalam konteks yang lebih luas.