Tim memperkirakan poin cerita, bisnis menginginkan waktu aktual

Saya yakin ini bukan tema yang tidak biasa. Kami memiliki dua tim scrum yang melakukan pekerjaan yang baik untuk memperkirakan cerita pengguna menggunakan poin cerita (rasi tim saat ini baru berusia sekitar 8 bulan, meskipun anggota tim memiliki pengalaman scrum beberapa tahun). Tetapi sulit bagi bagian bisnis perusahaan untuk berhubungan dengan cerita pengguna; mereka menginginkan unit waktu aktual (atau "formula untuk mengonversi poin cerita menjadi jam") sehingga mereka dapat membuat rencana kapan hal-hal akan siap ( "kita perlu tahu kapan kita bisa memberi tahu pelanggan bahwa Fitur X akan dalam produksi " ).

Saya, dan pendahulu scrum master saya, tentu saja telah menjelaskan bahwa "tidak ada hubungan yang pasti antara poin cerita dan waktu aktual" dan bahwa "poin cerita digunakan untuk menentukan berapa banyak tim dapat ditampung dalam sprint", dan saya yakin Anda bisa menebak seberapa puas mereka dengan jawaban itu. Mereka masih ingin tahu, dalam waktu kalender, kapan kita akan sampai ke cerita pengguna ke-27 di backlog.

Bagaimanapun, saya telah mengumpulkan beberapa statistik, dan perkiraan SP kami menerjemahkan ke dalam hasil aktual yang dihabiskan waktu yang sangat berbeda (seperti yang diukur oleh perangkat lunak scrum board kami, yang melacak berapa banyak waktu yang dihabiskan tiket di kolom "bekerja pada" ). Untuk cerita pengguna 1-SP, tentu saja ada bias berat menuju rentang waktu yang sangat singkat (dengan ledakan sesekali), tetapi terutama untuk cerita 2-SP, mereka ada di semua tempat: ada faktor 20 antara penyelesaian "tercepat" dan "paling lambat". Untuk 3, 5, dan 8-SP cerita, penyebarannya juga lebih dari faktor 2.

Ini menunjukkan bahwa (a) tim perlu lebih konsisten dalam memperkirakan cerita pengguna dari (apa yang seharusnya) kompleksitas yang sama, dan (b) tim perlu meningkatkan akurasi mereka dalam pelaporan waktu (mis. Mengingat untuk memindahkan tiket keluar dari "bekerja" saat mereka sedang rapat, saat makan siang, atau bermain bola basket).

Saya memiliki rencana untuk meningkatkan (a) dan (b) tetapi saya merasa itu tidak cukup, bahwa bisnis mengharapkan "lebih konkret" daripada apa yang akan dihasilkan oleh inisiatif ini.

Apa sajakah strategi yang baik dalam memenuhi tuntutan sisi bisnis , sehingga mereka tidak akan terlalu banyak mengganggu dalam cara kita bekerja (mis. Dengan memaksakan penggunaan pelacakan waktu terpisah, yang IMHO akan menjadi bodoh karena dalam hal apa pun akan kurang akurat daripada pelacakan "otomatis" saat ini), sementara pada saat yang sama memungkinkan mereka untuk mendapatkan ukuran konkret untuk kapan cerita akan dilakukan?

(Secara historis, selama perencanaan kami memang memecah cerita pengguna menjadi item pekerjaan yang kemudian secara individual diperkirakan dalam waktu kerja yang sebenarnya , tetapi yang saya bicarakan di sini adalah cerita pengguna di log belakang yang tidak akan memiliki tingkat detail atau istirahat -turun.)

Pembaruan: Manajer saya memiliki firasat bahwa ada semacam distribusi kurva lonceng dari jam-menghabiskan-per-cerita-point, tetapi data yang saya kumpulkan dan grafik yang dibuatnya benar-benar melumpuhkan dia dari gagasan itu. :-)

Anda benar, tidak ada rumus untuk mengonversi poin cerita menjadi jam. Anda bisa mendapatkan konversi meter ke kaki yang sangat mudah, dan sebaliknya, tetapi Anda tidak bisa mengatakan bahwa cerita 3 poin akan memakan waktu X jam, sehingga cerita 5 poin akan memakan waktu Y jam (pecahkan untuk Y).

HorusKol menyentuh bagian selanjutnya ini. Kecepatan sprint Anda sebagai sebuah tim dapat membantu dengan hasil jangka panjang. Katakanlah tim Anda 50 poin per sprint, dan setiap sprint adalah 2 minggu. Jadi 50 poin per sprint dikalikan 50 minggu dalam setahun (dengan asumsi orang mengambil libur 2 minggu untuk liburan) maka tim Anda saat ini dapat melakukan maksimal 2.500 poin dalam 12 bulan.

Jadi bisnis datang kepada Anda dengan 170 poin cerita dan epik. Bagilah dengan kecepatan historis tim sebesar 50 poin (rata-rata setiap sprint sejauh ini) dan Anda mendapatkan 3,4 sprint. Karena kami melakukan perkiraan, bulatkan hingga 4 sprint: 8 minggu. Dua bulan, pada dasarnya. Saya juga suka mengambil 3-4 sprint terakhir dan mengambil perkiraan lain. Katakanlah tim Anda dalam 3 sprint terakhir masing-masing menghasilkan 53, 67, dan 55 poin. Itu bekerja hingga 58-ish poin, yang pada tingkat itu adalah 2,9 sprint - jadi pada dasarnya 3 sprint. Sepertinya garis waktu Anda untuk 170 poin itu tampak seperti 6 hingga 8 minggu.

Katakan bisnis 2 bulan. Jangan beri tahu mereka 6-8 minggu, karena mereka hanya akan mendengar "6 minggu." Bahkan tidak memberi tahu mereka 8 minggu, karena sebagian besar bulan memiliki sekitar 4,5 minggu di dalamnya, dan ketika orang mendengar "4 minggu" mereka langsung berpikir "1 bulan." Setelah perkiraan mencapai sekitar 4 minggu, itu menjadi 1 bulan. Kemudian hanya bekerja berbulan-bulan. Jika Anda mencapai satu tahun atau lebih maka jujur ​​saja jangan memperkirakan pekerjaan itu. Tidak ada gunanya. Terlalu banyak yang bisa berubah dalam setahun.

Saya telah menemukan ini sebagai cara yang cukup akurat untuk mengkonversi poin cerita ke jam ... waktu yang baik, bagaimanapun.

Anda akan mendapatkan variasi dalam jumlah waktu yang dibutuhkan untuk menyelesaikan setiap cerita. Beberapa pengembang bekerja lebih cepat daripada yang lain. Menempatkan semua titik cerita ke dalam mangkuk dan menyalakan blender untuk bekerja dengan rata-rata membantu mengurangi ketidakkonsistenan tersebut.

Oh, dan jangan lupa bagian terpenting:

Pembulatan. Selalu.

Anda mungkin sudah memiliki beberapa konversi bawaan dari titik cerita ke perkiraan waktu - bagaimana Anda memutuskan bahwa Anda telah mengambil cukup banyak pekerjaan untuk sprint Anda? Anda mungkin mengatakan sesuatu seperti "tim dapat menangani 20 (atau 40 atau apa pun) poin seminggu". Setelah beberapa sprint, Anda harus dapat merevisinya berdasarkan penyelesaian - jadi sekarang 15 atau 25 (atau 35 atau 50 atau ...) menunjukkan sprint - ini adalah kecepatan tim Anda .

Untuk cerita pengguna 1-SP, tentu saja ada bias berat menuju rentang waktu yang sangat singkat (dengan ledakan sesekali), tetapi terutama untuk cerita 2-SP, mereka ada di semua tempat: ada faktor 20 antara penyelesaian "tercepat" dan "paling lambat". Untuk 3, 5, dan 8-SP cerita, penyebarannya juga lebih dari faktor 2.

Beberapa variasi waktu untuk menyelesaikan cerita tertentu baik-baik saja dalam nilai poin - kecepatan memperhatikan ketidakpastian itu dengan menjadi rata-rata dalam sejarah baru-baru ini.

Namun, Anda mungkin perlu mencermati bagaimana Anda menetapkan poin, terutama 2-pointer jika Anda mendapatkan fluktuasi yang begitu besar. Tugas titik yang lebih tinggi seharusnya tidak pasti (dan harus dipecah) - tetapi tugas sekecil 2-pointer harus cukup konsisten.

Karena semua tugas yang diberi nilai poin yang sama harus membutuhkan upaya yang sama, tidak masuk akal bahwa ada rentang waktu yang harus diselesaikan.

Jadi, lihat 2-pointer yang paling lama dalam retrospeksi Anda. Mengapa sesuatu yang mungkin seharusnya berubah menjadi slog 10 hari di pagi hari? Mungkinkah sesuatu telah ditandai pada pagi pertama itu untuk mengatakan "ini perlu menjadi dan epik dan dipecah menjadi tugas yang lebih kecil"? Begitu itu terjadi, tentu saja, pekerjaan ekstra yang diperlukan harus dimasukkan ke dalam tumpukan dan tidak mengganggu sisa sprint.

Juga, coba dan lihat bagaimana tim meremehkan item itu - dapatkah Anda melakukan lebih baik pada item yang akan datang setelah memeriksanya?

Ya, tanggal pengiriman akan didorong sesuai, atau daftar fitur untuk pembaruan dapat direvisi sehingga pengiriman tidak terpengaruh. Tetapi tujuannya adalah untuk meningkatkan estimasi titik masa depan, dan juga untuk mendapatkan garis waktu yang lebih akurat.

Ini seperti ramalan cuaca: semakin jauh, semakin tidak dapat diandalkan. Itu adalah analogi yang semua orang akan mengerti. Kesalahan dalam estimasi bertambah.

Penjualan harus belajar berbicara dalam istilah Scrum kepada pelanggan. Scrum tidak masuk akal secara terpisah, itu seharusnya diterapkan secara vertikal di seluruh perusahaan dan lebih disukai meluas ke ranah klien.

Anda sebagai tim pengembang harus tegas dalam hal ini. Anda dapat memberi mereka harapan dan tebakan tetapi jangan biarkan itu menjadi komitmen yang memperpanjang sprint tunggal.

Saya melakukan beberapa hal ketika mendapat pertanyaan seperti ini.

Pertama, saya menjawab pertanyaan tentang masa depan dengan menggambarkan masa lalu. Saya akan mengatakan sesuatu seperti Kami melewati sekitar dua cerita ini per minggu. Jadi, jika tidak ada yang berubah, kami berharap bisa menyelesaikan cerita 27 dalam waktu sekitar 14 minggu.

Kedua, saya ingin pelanggan menghadapi orang untuk bertanggung jawab atas jadwal perdagangan vs risiko. Saya akan mengatakan sesuatu seperti Ingat, tim teknik bekerja berdasarkan perkiraan 50/50. Jika tidak ada yang berubah, ada kemungkinan 50/50 kemungkinan fitur 27 siap dalam 14 minggu. Mungkin Anda tidak ingin melaporkan sesuatu dengan tingkat risiko seperti itu kepada pelanggan. Apakah Anda ingin saya menghitung perkiraan yang kami miliki, katakanlah, kepercayaannya 90%? Anda kemudian perlu meninjau bukti historis Anda dan mengatakan sesuatu seperti: Ada kemungkinan 90% bahwa cerita 27 akan dilakukan dalam 25 minggu .

Terakhir, ingatkan kolega Anda bahwa begitu dia membuat komitmen eksternal, perusahaan ditembaki. Membuat janji eksternal tentang kisah nomor 27 menghilangkan semua kelincahan perusahaan. Anda kemudian akan berkomitmen untuk tindakan tertentu. Setiap kali seseorang datang kepada Anda dengan permintaan perubahan, Anda sekarang perlu menjawab Kami telah berkomitmen untuk menyelesaikan cerita 27 sebelum x date. Saya hanya dapat melakukan perubahan ini jika Anda menghubungi pelanggan dan memberi tahu mereka bahwa komitmen kami tidak lagi valid. Pada dasarnya, membuat komitmen khusus untuk bekerja lebih dari sebulan atau lebih di masa depan datang dengan banyak masalah.

Anda telah memiliki konversi (sangat kasar):
Sprint scrum (biasanya) adalah dua minggu.
Anda tahu Anda bisa menyelesaikan, katakanlah, sekitar 20 poin poin fitur dalam dua minggu itu (atau bagaimana lagi Anda menentukan apa & berapa banyak fitur dimasukkan ke dalam satu sprint?) Dan sprint sebelumnya mengkonfirmasi perkiraan itu (katakanlah Anda menyelesaikan fitur poin poin 18, 21, 23, 19 dan 20 dalam lima sprint terakhir).

Katakanlah fitur X (dan semua dependensinya) telah diperkirakan sebagai 47 poin cerita.
Jadi Anda dapat memperkirakan bahwa jika Anda menerapkan itu pada prioritas tertinggi Anda harus mengambil sekitar 3 sprint, yaitu 6 minggu (tetapi pastikan bahwa perkiraan Anda memperhitungkan siapa yang dapat melakukan apa - jika 35 dari titik-titik itu adalah pekerjaan DB dan Anda hanya memiliki pada pria DB Anda perlu merevisi perkiraan kecepatan Anda untuk memperhitungkannya).

Yang mengatakan - tegas berkomunikasi bahwa itu adalah perkiraan kasar - ada alasan mengapa sprint adalah dua minggu dan bukan enam. Semakin banyak hal yang perlu dicakup oleh perkiraan Anda, semakin banyak ketidakpastian dan kesalahan yang menyelinap masuk. Juga dengan tegas mengomunikasikan biayanya - yaitu bahwa ini berarti menempatkan tugas di prioritas utama, artinya tidak ada tugas lain yang dikerjakan. Kalau tidak, Anda mungkin mengalami skenario:

"Kapan fitur Y dilakukan?"
"Jika kita fokus pada itu selanjutnya ... 12 minggu"
" 12 minggu?!? Kamu bilang akan butuh 4."
"Ya, tetapi kamu mengatakan kepada kami untuk memprioritaskan fitur X , yang kami katakan akan mengikat semua sumber daya kami dan memakan waktu 8 minggu."
"Tidak bisakah kamu bekerja pada fitur X dan fitur Y pada saat yang sama?"
" erangan "

Sprint adalah waktu yang ditentukan, katakanlah 2 minggu. Anda tidak dapat memprediksi beberapa cerita akan dilakukan lebih dari 2 sprint, seperti Anda memiliki sprint Anda saat ini dan sprint berikutnya. Saya berasumsi Anda telah menyiapkan cerita yang dibahas dengan tim untuk sprint berikutnya dan diprioritaskan oleh bisnis. Jadi yang terbaik yang bisa Anda katakan pasti adalah 4 minggu ke depan kerja.

Semuanya lebih dari 4 minggu dapat berubah dan bisnis dapat membuat peta jalan yang tidak ditetapkan dalam jam. Itu harus direncanakan per sprint, katakanlah beberapa epik1 (epik seperti dalam jira banyak cerita yang dikelompokkan) dan epik2 harus dilakukan dalam sprint 47 dan 48 dan epic3 harus dilakukan dalam sprint 49. Epik saya memperkirakan kira-kira dalam hitungan jam sendiri untuk lihat apakah satu atau dua akan muat dalam sprint, toh timeline akan tergelincir. Jika fitur tidak berfungsi, bisnis harus memotong ruang lingkup atau menerima solusi yang tidak sempurna yang dapat diperbaiki nanti sesuai kebutuhan (yang harus gesit, merangkul kenyataan alih-alih mengikuti rencana).

Anda dapat membuat bagan Gantt yang bagus (seperti itulah bisnis) dengan sprint masa depan dan topik / epos utama untuk mereka.

Saya suka membuat rilis setiap sprint dan kemudian saya mempersiapkan rilis dengan apa yang selesai dalam sprint (atau hal-hal yang ditandatangani untuk dirilis oleh bisnis meskipun tidak sempurna), hal-hal yang belum selesai pergi ke sprint berikutnya. Dengan cara ini saya memiliki pengiriman yang dapat diprediksi dalam waktu sekitar 2-3 minggu (satu minggu untuk perbaikan pada kandidat rilis).

Itulah pengalaman saya dengan tim kecil, jumlah kecil ketergantungan luar dan apa yang saya yakini bisnis yang masuk akal. Jarak Anda mungkin beragam.

Untuk fitur baru, hampir tidak mungkin memperkirakan waktu yang diperlukan.

Pengalaman dengan pengembangan perangkat lunak menunjukkan bahwa dalam kebanyakan kasus ada detail yang tidak dapat Anda lihat sebelum benar-benar memulai pengembangan. Dalam kasus terbaik, deteils tersebut mungkin memerlukan waktu tambahan, tetapi dalam kasus terburuk proyek juga dapat gagal. Alasan untuk itu adalah kompleksitas pengembangan perangkat lunak itu sendiri.

Ini adalah alasan mengapa SCRUM hanya memperkirakan kompleksitas masalah (poin cerita), tetapi bukan waktu. Satu-satunya peluang yang Anda miliki adalah memisahkan fitur dengan kompleksitas tinggi menjadi lebih kecil. Dengan cara ini Anda bisa meminimalkan risiko.

Karena perkiraan waktu hampir tidak mungkin, tidak ada rumus yang mengubah poin cerita menjadi perkiraan waktu. Kecepatan hanya bisa menjadi perkiraan yang sangat kasar, tidak lebih.

Di SCRUM, pemilik produk dapat mengubah prioritas item backlog sebelum setiap sprint. Oleh karena itu master SCRUM tidak dapat memberikan perkiraan apa pun untuk lebih dari satu sprint. Dia tidak tahu item backlog mana yang mungkin menjadi penting dalam sprint berikutnya.

SCRUM bukanlah metode untuk melakukan hal-hal yang tidak mungkin (rencanakan yang tidak dapat direncanakan) atau membuat pengembangan lebih cepat. Ini adalah sistem peringatan dini jika pembangunan kehabisan waktu. Ini memungkinkan untuk bereaksi dengan cepat pada persyaratan baru.

Ke pos awal:

Anda sudah sangat baik jika Anda mengelola pemisahan sebagian besar tugas Anda menjadi 1 SP hingga 5 cerita SP. Perkiraan kecepatan mungkin lebih baik jika tugasnya serupa dan tim Anda menjadi lebih berpengalaman. Tetapi jika selalu ada bagian yang baru dan tidak layak dalam item baru, Anda harus hidup dengan ketidaktepatan tersebut.

Karena biasanya pengembang Anda menghabiskan waktu dengan pekerjaan non-pengembangan (mis. Rapat), Anda tidak boleh merencanakan dengan 8 jam pengembangan untuk setiap hari, tetapi lebih sedikit, misalnya 6 jam. Kemudian Anda mendapatkan cadangan untuk tugas-tugas lain atau untuk item pekerjaan yang membutuhkan lebih banyak waktu.

Jika kolega bisnis Anda ingin memiliki perkiraan yang akurat (yang merupakan kontradiksi dalam dirinya sendiri), jelaskan kepada mereka masalah bawaan pengembangan perangkat lunak. Kemudian tunjukkan pada mereka keuntungan dari metode tangkas.