Banyak kisah pengguna berbagi tugas teknis yang sama: apa yang harus dilakukan?

Sedikit pengantar untuk kasus saya:

Sebagai bagian dari produk yang lebih besar, tim saya diminta membuat IDE kecil untuk DSL. Pengguna produk ini akan dapat membuat panggilan fungsi dalam kode dan kami juga diminta untuk menyediakan beberapa pustaka fungsi yang berguna. Tim, bersama-sama dengan PO, menempel di dinding sejumlah cerita pengguna tentang berbagai perpustakaan untuk pengguna IDE. Ketika memperkirakan cerita pertama, tim memutuskan bahwa mekanisme pemanggilan fungsi akan menjadi tugas yang menarik tetapi tidak sepenuhnya jelas, sehingga perkiraan untuk cerita pengguna tersebut dinaikkan dari angka 3 yang sederhana menjadi yang lebih berbahaya 5.

Datang ke masalah:

Tim kemudian pindah ke cerita pengguna tentang perpustakaan lain, sebenarnya 10 cerita, dan menambahkan 2 poin hal " mekanisme panggilan fungsi " ke masing-masing cerita pengguna. Ini segera mengangkat total poin untuk produk 20 poin! Semua orang di tim tahu bahwa setiap cerita pengguna dapat diambil oleh PO untuk iterasi berikutnya kapan saja, jadi kami tidak boleh mengisolasi bagian itu dalam satu cerita pengguna, tetapi 20 poin itu terasa sangat tidak realistis!

Saya sudah mengusulkan solusi, tapi saya sama sekali tidak puas:

Kami membuat "Cerita desain" dan menempatkan 2 poin yang menjengkelkan di atasnya. Namun ketika kami menyadari dan menunjukkannya kepada pelanggan kami, kami tidak dapat menunjukkan sesuatu yang sangat berharga bagi mereka tentang kisah itu!

Di sini masalahnya adalah apakah kita harus mengabaikan prinsip memiliki cerita pengguna yang terisolasi (tanpa ada ketergantungan di antara mereka).

Apa yang akan Anda lakukan, atau bahkan lebih baik apa yang telah Anda lakukan, dalam situasi seperti ini?

(catatan kaki kecil: mengikuti saran saya telah memindahkan pertanyaan ini dari stackoverflow)

Jika Anda perlu memperkirakan beberapa cerita-pengguna yang memiliki beberapa elemen yang sama, tetapi Anda belum tahu bagaimana urutan cerita-cerita ini untuk diimplementasikan, maka saya akan membagi tugas-tugas yang membentuk setiap cerita menjadi tiga kelompok:

1. Tugas umum, diperlukan sekali : Tugas yang terjadi untuk banyak cerita, tetapi yang hanya harus dilakukan hanya sekali untuk cerita pertama. Mekanisme panggilan fungsi yang disebutkan mungkin akan jatuh dalam kategori ini.
2. Tugas yang umum dan berulang : Tugas yang muncul dalam banyak cerita dan harus dieksekusi lagi untuk setiap cerita.
3. Tugas khusus : Tugas yang khusus untuk cerita tertentu.

Kemudian Anda memperkirakan setiap tugas, di mana tugas umum harus diperkirakan hanya satu kali.

Dalam presentasi kepada pelanggan / PO, saya akan memberikan dua perkiraan untuk setiap cerita: Satu dengan semua tugas "umum, diperlukan sekali" termasuk dan satu dengan mereka dikeluarkan.
Pertahankan pembukuan terinci dari tugas-tugas tersebut, klasifikasi dan estimasi mereka di tangan jika pelanggan menginginkan informasi yang lebih terperinci tentang perbedaan antara perkiraan tersebut. Tugas-tugas itu sendiri tidak dapat dinegosiasikan, tetapi mengetahui tentang mereka dapat membantu pelanggan / PO, terutama jika serangkaian tugas umum tidak sama untuk setiap cerita.

Mengapa perangkat lunak itu sulit.

Kami membuat "Cerita desain" dan menempatkan 2 poin yang menjengkelkan di atasnya. Namun ketika kami menyadari dan menunjukkannya kepada pelanggan kami, kami tidak dapat menunjukkan sesuatu yang sangat berharga bagi mereka tentang kisah itu!

Benar. Kisah pengguna sederhana SCRUM adalah sederhana. Terkadang, perangkat lunak yang sebenarnya cukup kompleks sehingga pendekatan sederhana tidak berfungsi. Seharusnya ini tidak mengejutkan.

Di sini masalahnya adalah apakah kita harus mengabaikan prinsip memiliki cerita pengguna yang terisolasi (tanpa ada ketergantungan di antara mereka).

Apa alternatif Anda? Harga lebih tinggi dari setiap cerita pengguna karena masing-masing memiliki biaya satu kali tersembunyi? Itu sama konyolnya.

Iya. Anda harus menjauh dari simplistik.

Apa yang akan Anda lakukan, atau bahkan lebih baik apa yang telah Anda lakukan, dalam situasi seperti ini?

Minggir dari penyederhanaan. Ada investasi satu kali yang membuat sekelompok cerita lebih murah. Anda harus benar-benar berbicara dengan orang-orang tentang arsitektur alih-alih berpura-pura bahwa satu-satunya interaksi Anda adalah daftar cerita yang akan dibangun.

Agile berarti Anda harus benar-benar berbicara dengan PO dan pelanggan.

Agile berarti proses penyederhanaan tidak bisa - dan tidak akan - berhasil.

Anda tahu bahwa Anda hanya perlu melakukan pekerjaan ekstra sekali, jadi memasukkan pekerjaan tambahan yang sama ke dalam 5 cerita tidak masuk akal. Jika Anda tidak ingin cerita desain yang tidak dapat dilihat pengguna, maka hal terbaik yang harus dilakukan adalah terus maju, sekarang, dan memilih salah satu hal yang bergantung pada pekerjaan desain itu dan mengatakan bahwa itu harus menjadi yang pertama dan tambahkan poin-poin itu ke yang itu. Buat catatan tentang cerita-cerita lain yang harus mereka sampaikan nanti, dan jika, karena alasan tertentu, Anda berubah pikiran, Anda selalu dapat memindahkan poin-poinnya.