Saya pikir jawaban Frank dan Encaita cukup banyak membahasnya tetapi ada beberapa hal tambahan untuk dipertimbangkan:
Mengapa menggunakan poin cerita
Tujuan memperkirakan dengan poin cerita adalah untuk memberikan kompleksitas relatif dari pengembangan fitur untuk aplikasi Anda. Cara mudah untuk memikirkannya adalah dengan mengambil cerita yang Anda miliki di sprint yang akan datang misalnya perubahan url. Anda tahu ini sederhana dalam hal kompleksitas, dan telah menetapkan kriteria penerimaan dengan jelas sehingga seluruh tim setuju bahwa meskipun dengan pengujian itu adalah 1 (menggunakan skala Fibo).
Kisah selanjutnya yang akan diperkirakan adalah mengumpulkan seperangkat data pengguna dan memvisualisasikannya di ujung depan. Sekarang sebagai pengembang Anda segera tahu ini jauh lebih kompleks daripada mengubah url. Anda mendiskusikan cerita dan kriteria penerimaan dan Anda memiliki banyak pertanyaan dan dapat melihat beberapa solusi potensial untuk melakukan ini. Para pengembang dan QA yang lain juga setuju itu sangat kompleks. Jadi Anda semua setuju bahwa itu adalah cerita 34 poin. Perlu dicatat bahwa skala Fibo juga memungkinkan Anda untuk menunjukkan seberapa besar kepercayaan yang Anda miliki pada perkiraan - semakin besar kesenjangan antara angka menunjukkan semakin sedikit kepercayaan yang Anda miliki dalam perkiraan Anda
Pada titik ini, master Scrum Anda harus melompat dan mengatakan bahwa ini sebagai cerita tunggal terlalu besar dan perlu dipecah menjadi cerita yang lebih kecil dengan kompleksitas yang lebih sedikit. Anda dapat melakukan pendekatan ini dengan melakukan apa yang dikenal sebagai SPIKES - ini hanya waktu yang disediakan untuk menyelidiki sesuatu. Jadi untuk contoh ini Anda dan para pengembang lainnya setuju bahwa Anda ingin 4 jam untuk membahas dan menyelidiki solusi teknis yang memungkinkan.
Singkat cerita, Anda membagi cerita besar itu menjadi empat cerita lain dengan 5, 8, 8, dan 13 poin. Tidak ingat bahwa perkiraan ini adalah semua tentang kompleksitas relatif - mereka tidak harus menambahkan hingga perkiraan awal ditambah Anda memiliki lebih banyak informasi sekarang untuk membuat perkiraan yang lebih akurat.
Anda kemudian setuju sebagai tim bahwa untuk sprint ini Anda akan bertujuan menyelesaikan cerita 13 poin, satu cerita 8 poin ditambah perubahan 1 poin url yang sudah Anda identifikasi. Jadi total 22 poin. Sprint berikutnya Anda mendapatkan 27 poin, sprint berikut Anda mendapatkan 18 poin. Setelah 3 sprint, Anda bisa mulai percaya pada kecepatan Anda (kecepatan adalah jumlah pekerjaan yang bisa dilakukan tim Anda dalam satu sprint). Untuk mendapatkan kecepatan, ambil rata-rata sprint sebelumnya. Jadi dalam contoh ini rata-rata adalah (22 + 27 + 18) / 3 = 22,3 jadi bulatkan ke yang terdekat pada skala Fibo yaitu 21.
Sekarang untuk sprint berikutnya hanya bertujuan untuk menyelesaikan 21 poin.
Jangan terpaku untuk mendapatkan perkiraan titik cerita Anda dengan benar - itu bukan ilmu pasti. Anda tahu perubahan url jauh lebih kompleks daripada mengumpulkan data, jadi beri nilai saja.
Ditambah membahas hal-hal ini sebagai tim yang baik. Lihat kembali perkiraan Anda selama ulasan sprint dan diskusikan apakah Anda senang dengan mereka atau tidak dan kemudian masukkan ini ke dalam sesi perencanaan sprint berikutnya.
Perkiraan seluruh tim
Seluruh tim harus menyetujui estimasi tunggal untuk setiap cerita. Sebuah fitur tidak selesai sebelum siap diproduksi. Hanya mendapatkan kode yang ditulis tidak berarti dilakukan. Dalam pengalaman saya, tim Scrum jauh lebih efektif ketika bekerja sebagai sebuah tim. Ambil contoh tim yang sedang bekerja sama dengan saya sekarang. Ketika saya bergabung, mereka melakukan semua rapat sprint dan merencanakan poker tetapi selama sprint prosesnya adalah 1. BA / Pemilik Produk mendefinisikan persyaratan sebagai cerita dengan kriteria penerimaan dan tes penerimaan 2. Mereka menyerahkan persyaratan ini kepada pengembang yang kemudian menulis kode 3. Pengembang memiliki kode yang digabungkan ke cabang pengembangan untuk QA untuk menguji 4. Tes QA kemudian mereka mulai mengajukan pertanyaan dan tes gagal sehingga kembali ke pengembangan.
Apa yang hilang di sini? Tidak ada cukup diskusi di muka dan setiap anggota tim hanya melihat tugas mereka sendiri. Sekarang BA / PO, devs dan QA berkumpul sebelum menulis kode apa pun untuk membahas persyaratan secara rinci dan mengajukan pertanyaan di muka, kemudian melanjutkan diskusi sepanjang sprint. Ini jauh lebih efisien dan mengarah ke solusi kualitas yang lebih baik.
Perencanaan poker membantu proses ini karena memaksa tim untuk membahas fitur dan setuju, sebagai tim, betapa rumitnya pengiriman fitur itu. Dalam pengembangan perangkat lunak tradisional, Manajer Proyek bertanggung jawab atas pengiriman proyek, tetapi siapa pun yang berpengalaman dengan pendekatan itu tahu itu tidak berhasil karena lebih sering daripada tidak, orang tidak bertanggung jawab atas peran mereka dalam pengiriman aplikasi. Di Agile Anda tidak perlu manajer proyek karena tim bertanggung jawab secara keseluruhan untuk pengiriman aplikasi.
Estimasi tugas tepat waktu
Pandangan saya bekerja dengan tim yang memperkirakan waktu untuk tugas dan tim yang hanya melakukan perkiraan titik cerita adalah JANGAN MELAKUKAN ESTIMASI WAKTU! Mereka sebenarnya hanya buang-buang waktu. Mereka tidak seakurat poin cerita karena mereka khusus untuk individu bukan tim, dan masing-masing individu akan memiliki ide yang berbeda tentang estimasi waktu (membawa nyala api).
Poin cerita menerima bahwa hal-hal yaitu persyaratan, berubah sepanjang waktu sehingga Anda benar-benar memerlukan indikator apa yang dapat diselesaikan tim dalam sprint.
Setelah Anda memahami kecepatan, Anda dapat mengukur kiriman Anda tepat waktu karena Anda tahu apa yang bisa Anda lakukan di setiap sprint misalnya setiap dua minggu Anda tahu fitur apa yang dapat disampaikan. Pemilik scrum master dan pemilik produk Anda harus memiliki sesi estimasi untuk melihat ke depan untuk sprint di masa depan maka Anda bisa mendapatkan indikator seberapa banyak pekerjaan yang akan Anda lakukan dalam beberapa bulan mendatang. Ini memungkinkan pemilik produk untuk membuat keputusan penentuan prioritas tentang fitur apa yang akan dimasukkan dalam aplikasi akhir.
Saya sudah meminta pengembang untuk memperkirakan waktu untuk tugas-tugas untuk merencanakan tetapi saya sebenarnya tidak setuju dengan pendekatan ini (sebenarnya saya sangat tidak setuju dengan pendekatan ini) karena tidak akurat misalnya apa yang akan saya perlukan 4 jam: satu dev mungkin hanya memasukkan waktu untuk tugas itu sendiri, orang lain mungkin menambahkan waktu untuk membuat cangkir teh!
Perkiraan waktu selalu diserahkan kepada orang lain untuk tujuan pelaporan dan itu juga terlalu menekankan elemen individu dalam memberikan fitur vs seluruh upaya tim.
Estimasi bukanlah masalah terbesar
Selain itu, mencari tahu estimasi bukanlah masalah terbesar yang saya pikir harus diselesaikan oleh tim. Yang paling penting adalah bekerja bersama sebagai tim untuk menyelesaikan semua hal dalam sprint, sehingga Anda tidak menyerahkan semuanya untuk pengujian pada hari terakhir. Anda ingin melihat tetesan fitur di sepanjang sprint 2 minggu. Tim dinamis yang saya jelaskan di atas adalah sebagian besar dari ini. Perkiraan titik cerita akan membantu Anda merencanakan hal ini karena Anda akan melihat cerita besar mana yang perlu dipecah menjadi yang lebih kecil yang dapat dikirim ke pengujian secara teratur.