Apakah boleh mengubah perkiraan di tengah iterasi?


14

Kami sudah mulai menggunakan Agile / Scrum dalam tim yang terdiri dari 4 pengembang. Kami melakukan estimasi cerita kami dan memesan cerita-cerita tersebut dengan cerita-cerita utama dalam tumpukan produk.

Kami mulai dengan estimasi berbasis poin pada kompleksitas dari 1 hingga 5, bukannya 1,2,3,5,8,13 biasa .... dan seterusnya

Setelah mengerjakan beberapa cerita, kami merasa bahwa beberapa cerita yang diperkirakan 4 poin seharusnya hanya 2 sedangkan yang lain diperkirakan 2 jauh lebih kompleks dan seharusnya diperkirakan 5. Saya ingin tahu:

  • Apakah boleh mengubah perkiraan cerita kami di tengah iterasi?
  • Apakah boleh menggunakan titik estimasi saat ini dari 1 hingga 5, bukannya 1,2,3,5,8,13 biasa .... dan seterusnya

Meskipun saya pribadi merasa bahwa itu tidak boleh untuk kedua kasus tetapi saya harus mendukung diri saya sendiri karena pemahaman saya sendiri tidak terlalu jelas. (Bahan ref yang bagus akan bagus!)


4
Tanyakan pada diri Anda: apa manfaat dari menghabiskan waktu menaksir ulang sprint tengah? Apa manfaat dari menghabiskan lebih banyak waktu 'berdebat' tentang berbutir halus 3 vs 4 vs 5 dibandingkan dengan kasar 3 vs 5?
Hugo

Jawaban:


13

Apakah boleh mengubah perkiraan cerita kami di tengah iterasi?

Benar-benar tidak. Kami berharap itu terjadi. Dan kami berharap kesalahan akan menyeimbangkan diri dari waktu ke waktu. Kami hanya benar-benar menyesuaikan taksiran di mana jelas bahwa kategori tertentu (mis. Laman web baru) selalu akan lebih kompleks daripada yang kami pikirkan saat kami mengestimasi semuanya.

Karena sebuah kisah Epik dipecah menjadi cerita-cerita yang lebih kecil (yang seharusnya terjadi jauh sebelum sprint), kita mungkin tampak menyesuaikan perkiraan aslinya, tetapi saya akan menyebutnya penyempurnaan daripada reestimating. Itu karena kami memiliki pandangan yang lebih jelas saat itu.

Agile Estimating and Planning Mike Cohn adalah buku yang bagus tentang masalah ini. Saya akan memperingatkan agar tidak menggunakannya (atau buku "Agile") sebagai kitab suci, tetapi ini adalah titik awal yang baik untuk memperbaiki proses Anda.

Dia berbicara tentang cara perkiraan yang keliru menyeimbangkan sebagai "sihir", tetapi menekankan bahwa dia telah melihatnya bekerja berulang-ulang.

Apakah boleh menggunakan titik estimasi saat ini dari 1 hingga 5, bukannya 1,2,3,5,8,13 biasa .... dan seterusnya

Penggunaan seri estimasi poin Fibonacci adalah penerimaan bahwa semakin besar sebuah cerita, semakin tidak akurat estimasi kami (lihat komentar saya sebelumnya tentang Epos).

Tetapi, jika itu tidak berhasil untuk Anda, terutama jika Anda menjaga semua pekerjaan Anda kecil, maka jangan menggunakannya. Itu adalah pedoman, bukan aturan.

Ukuran kaos (SML XL XXL) juga populer dan pada dasarnya tidak berbeda dengan (1 2 3 4 5).


+1: Diskusikan ini selama retrospeksi Anda. Perkirakan kembali ketika Anda memprioritaskan kembali pada awal musim semi berikutnya. Itu sebabnya Anda memiliki sprint. Tidak ada overhead manajemen selama sprint - cukup buat kode.
S.Lott

Tentang penggunaan penggunaan seri fabonacci, Katakan Anda tahu bahwa sebuah cerita akan memakan waktu hampir 3 hari dan tidak. tugas untuk melakukan cerita adalah A, B, C. Anda juga merasa bahwa itu tidak terlalu rumit tetapi masing-masing tugas ini akan memakan waktu masing-masing 1 hari. Berapa perkiraan yang akan Anda berikan untuk cerita itu?
tintin

@tintin: Alasan menggunakan poin adalah untuk menghindari mengatakan hal-hal seperti "Anda tahu bahwa sebuah cerita akan memakan waktu hampir 3 hari." Poin relatif sewenang-wenang, setiap pekerjaan didasarkan pada kompleksitas dibandingkan dengan pekerjaan lain (jelas Anda harus menghindari menggunakan pekerjaan yang salah estimasi sebagai baseline). Tapi, Anda menghindari angka yang hilang, untuk memperhitungkan ketidakpastian. Jadi, jika pekerjaan B dua kali lebih kompleks dari pekerjaan A dan pekerjaan A ditandai sebagai 2 poin, Anda menandai pekerjaan B sebagai 5 poin.
pdr

+1 untuk: semakin besar sebuah cerita, perkiraan kami kurang akurat
kevchadders

1

Apakah boleh mengubah perkiraan cerita kami di tengah iterasi?

Benar-benar ya - jika itu akan memengaruhi perencanaan musim semi saat ini atau di masa depan. Intinya lincah adalah mendasarkan tindakan Anda pada informasi yang terbaru dan benar mungkin.

Jika perkiraan ternyata sangat salah sehingga sprint saat ini tidak dapat diselesaikan di kotak waktu, Anda harus bertindak berdasarkan perkiraan yang direvisi, jadi Anda mungkin ingin mengubahnya. Jika Anda mendasarkan perkiraan baru pada yang lama (dan benar-benar melihat itu daripada mengandalkan memori / pengalaman), Anda perlu benar.

Di sisi lain, sebenarnya tidak ada nilai per se dalam perkiraan yang benar. Jangan buang waktu untuk menghitung statistik yang tidak berarti.


Dalam kasus kami, estimasi awal adalah yang besar, dan pekerjaan untuk itu ternyata jauh lebih sedikit. Jadi bukan karena sprint kami saat ini tidak selesai dalam waktu tetapi kami memiliki waktu ekstra. Jadi manajer menyarankan untuk menurunkan estimasi.
tintin

@Michael, jawaban ini mungkin benar untuk beberapa proses lincah tetapi pertanyaannya berkaitan dengan Scrum. Di Scrum, tidak disarankan untuk mengubah poin cerita setelah perencanaan sprint karena metrik Velocity tim dapat dikompromikan.
GuyR

Estimasi yang gagal membawa manfaat karena Anda dapat menggunakannya untuk menyesuaikan estimasi yang akan datang. Jika Anda memperkirakan terlalu lama, terlalu banyak gagal daripada memperkirakan terlalu pendek, karena hasilnya adalah sumber daya yang kurang dimanfaatkan. Nilai dalam perkiraan yang benar adalah Anda tahu bahwa Anda kemungkinan besar akan mencapai target rilis Anda, dan tim Anda dimanfaatkan sepenuhnya. Oleh karena itu, Anda selalu mendasarkan estimasi masa depan pada pengalaman masa lalu Anda, menyesuaikan sesuai dengan apa yang Anda pelajari tentang estimasi Anda sepanjang jalan.
S.Robins
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.