Bagaimana Poin Cerita Tim yang Dewasa

Saya baru-baru ini ditanya oleh pengguna apakah saya memiliki cara menganalisis kedewasaan tim dengan cara mereka menunjuk.

Hal ini membuat saya berpikir: hal-hal apa yang dilakukan (atau tidak dilakukan) tim Scrum baru jika dibandingkan dengan tim veteran? Ini bukan algoritme yang rapi untuk menilai tim Anda, tetapi mudah-mudahan, ini akan membantu memandu tim Anda ke arah yang Anda inginkan.

Apa poin cerita?

Apa pun yang pernah Anda baca tentang scrum akan memberi tahu Anda: poin cerita mengukur kompleksitas, bukan waktu.

Ini konsep yang sulit didapat; butuh waktu 5 tahun untuk akhirnya memahami nuansanya.

Mengungkit perbedaan antara waktu / kompleksitas tampaknya tidak masuk akal secara intuitif. Misalnya, jika ada sesuatu yang rumit, saya akan membutuhkan lebih banyak waktu. Dan jika sederhana, seharusnya cukup cepat. Kenapa repot-repot?

Mari kita kembali ke alasan pertama mengapa kita menggunakan Scrum, atau XP, atau yang seperti ini. Di masa lalu, kami biasa membuang waktu untuk rapat, membuat bagan Gantt, memberikan perkiraan, dan membuat proyeksi – semuanya selalu salah! Jadi kami membuang banyak waktu untuk melakukan hal-hal yang tidak dapat dipercaya.

Kami diberi tahu bahwa poin cerita ditemukan karena “perkiraan waktu tidak akurat.” Ini benar, tetapi banyak orang berpikir ini menyiratkan bahwa poin cerita lebih akurat daripada perkiraan waktu. Bukan itu masalahnya. Perkiraan waktu tidak akurat, begitu pula poin cerita.

Poin cerita lebih baik karena lebih fleksibel. Mereka membuat proses estimasi dan proyeksi lebih efisien. Tim Anda dapat menghabiskan lebih sedikit waktu untuk perencanaan dan lebih banyak waktu untuk melakukan pekerjaan yang menghasilkan nilai, yang kita semua inginkan. Dan dengan poin cerita yang tepat, perencanaan dan proyeksi Anda akan menjadi lebih akurat. Ini adalah kemenangan di sekitar.

Apa yang dimaksud dengan “kompleksitas”?

Ini sulit untuk dipahami dan lebih mudah dijelaskan dengan sebuah contoh.

Pada hari ke-1, Anda memiliki simpanan cerita, tanpa perkiraan. Jadi tim membaca seluruh backlog dan memilih salah satu yang berukuran “sedang” – dan menetapkannya sebagai media dalam poin, mungkin 8. Ini adalah cerita “batu kunci” Anda.

Kemudian Anda menelusuri setiap cerita di backlog dan membandingkannya dengan keystone. Apakah lebih kompleks atau kurang kompleks? Jika kurang rumit, cerita itu adalah 5. Jauh lebih mudah, itu adalah 3.

Anda tahu bahwa sebuah cerita lebih atau kurang rumit oleh beberapa faktor. Apakah ada beberapa hal yang tidak diketahui? Tidak diketahui membuatnya lebih kompleks. Apakah sulit untuk menguji? Itu lebih kompleks. Apakah itu bergantung pada API pihak ketiga? Itu lebih kompleks.

Setiap kali pengembang Anda berkata, “Saya perlu melakukan beberapa penelitian,” itu berarti itu lebih kompleks. Pilih angka yang lebih besar dan lanjutkan.

Jangan samakan poin dengan waktu

Orang suka menyamakan poin cerita dengan waktu – ini salah. Mengapa? Saat tim matang, kecepatan mereka harus meningkat. Tetapi jika 5 poin = 1 hari (atau apa pun yang Anda pilih)… apa yang terjadi pada cerita 5 poin yang berusia 6 bulan? Dulu menghabiskan satu hari, tapi sekarang hanya 3/4 sehari. Mungkin sekarang harus 3 poin? Jika Anda tidak terus-menerus memperbarui poin Anda, maka Anda tidak dapat memproyeksikan tanggal penyelesaian Anda.

Jika poin Anda tidak sesuai dengan waktu, dan tim Anda semakin cepat, Anda hanya perlu meningkatkan kecepatan sprint. Kecepatan kami dulu 90 poin per sprint, tetapi sekarang kami memiliki server build baru, kami dapat melakukan 94 poin per sprint. Tidak perlu memperkirakan ulang seluruh simpanan untuk membuat proyeksi yang akurat tentang masa depan.

Jika poin berhubungan dengan waktu, lalu mengapa menggunakan poin? Poin awalnya disusun karena pengembang MENGERIKAN dalam memperkirakan waktu. Itu bukan salah mereka, ini pekerjaan yang rumit dan sangat sulit untuk dilakukan.

Berikut adalah beberapa indikator yang ditunjukkan oleh tim Anda seiring waktu, alih-alih kerumitan:

Seorang pengembang berkata, “Saya tidak bisa menunjukkan sesuatu karena saya perlu melakukan lebih banyak penelitian.”

Tidak selalu, tapi berkali-kali, ini pertanda penggunaan waktu. Mereka ingin membahas semua detailnya, sehingga mereka bisa menebak waktu yang dibutuhkan.

Seorang pengembang berkata, “Ini adalah 3 jika saya mengerjakannya, tapi 5 jika Jerry melakukannya”

Ini adalah pengukuran waktu lainnya. Apa yang mereka katakan adalah lebih sedikit waktu jika saya melakukannya. Tapi dengan poin cerita, kami tidak peduli siapa yang melakukannya. Kami tahu kecepatan rata-rata tim adalah 90 poin per sprint. Jerry mungkin menghabiskan lebih banyak waktu untuk tugas ini, tetapi itu berarti saya sedang mengerjakan sesuatu yang lain. Jadi ikuti saja rata-rata dan jangan khawatir tentang secara spesifik siapa yang mungkin melakukan pekerjaan itu.

Jangan memperdebatkan perbedaan poin kecil

Kami tidak memperdebatkan perbedaan poin kecil. Jika 1, 2, atau 3, itu tidak terlalu penting. Jika banyak orang mengatakan 1, beberapa mengatakan 2, dan satu orang mengatakan 3… kita tetap memilih 3. Tidak ada gunanya membahas perbedaan 1 poin. Pilih yang besar dan maju.

Jangan terobsesi dengan perkiraan yang sempurna

Kami tidak khawatir tentang menjadi sempurna, kami memotret hingga 80% benar. Ketika tim baru mengenal scrum, banyak penekanan diberikan pada estimasi yang sempurna, karena sebelum scrum, kami selalu membutuhkan estimasi yang sempurna. Terkadang sebuah organisasi bahkan menuntut tim scrum memiliki perkiraan yang sempurna. Ini tidak baik dan sesuatu yang harus ditangani oleh Scrum Master dengan kerja keras. Setelah tim pengembangan berada di tempat yang aman, mereka dapat dengan cepat menetapkan poin dan mulai bekerja. Karena menyelesaikan pekerjaan adalah nama asli dari permainan tersebut. Poin-poinnya ada hanya untuk membantu Anda melihat ke masa depan dan memproyeksikan kapan beberapa pencapaian akan tercapai. Akurasi 80% adalah sweet spot. Lebih baik dari itu dan Anda membuang banyak waktu dalam perencanaan. Lebih buruk dari itu dan perusahaan lainnya tidak dapat merencanakan secara akurat.

Jangan menyerah pada tekanan untuk mengubah sejumlah poin

Mungkin sulit saat Anda memiliki PO yang menuntut yang mengatakan, “apakah ini benar-benar 5, bukankah seharusnya 3?” Atau beberapa eksekutif berkata, “mengapa Tim A menyelesaikan 100 poin, tapi Tim B hanya 75?”

Tim yang kurang matang akan hancur di bawah tekanan. Mereka akan mencoba untuk menyelesaikan 5 dalam waktu 3 dan akhirnya tidak akan berhasil. Ini mungkin langsung terlihat jelas karena mereka tidak menyelesaikan seluruh sprint. Atau mungkin muncul di jalan karena hutang teknis ditambahkan. Semua orang akan melihatnya dalam beberapa bulan ketika fitur baru membutuhkan waktu lebih lama dari yang diharapkan atau penuh dengan bug.

Atau ketika eksekutif membuat mereka merasa tidak enak karena tidak melakukan jumlah poin yang sama; tim yang kurang matang hanya akan menambah jumlah mereka. Mereka tidak benar-benar meningkatkan kecepatan.

Tim yang matang tahu bahwa mereka bertanggung jawab atas kualitas. Tidak ada orang lain. Jika seseorang ingin mereka menyelesaikan sesuatu dengan harga lebih murah, mereka akan membicarakannya. Mereka menjelaskan pengorbanan dan hutang teknis yang akan dihasilkan.

Dan jika seorang eksekutif menyiratkan bahwa produktivitas mereka lebih rendah, mereka akan menggali lebih dalam. Mungkin eksekutif itu membandingkan apel dengan jeruk dan sampai pada kesimpulan yang salah? Atau mungkin produktivitas tim yang matang sebenarnya lebih rendah? Saya mengharapkan tim yang matang untuk menggali, mencari tahu apa yang salah (jika ada), dan membuat perubahan yang sesuai untuk meningkatkan. Mereka tidak hanya memasukkan angka mereka untuk memuaskan kekuatan yang ada; itu tidak membantu siapa pun.

Bagaimana dengan anda Apakah Anda pernah mengalami sesuatu yang membedakan tim yang matang? Tolong bagikan; kami akan memperbarui artikel ini dengan tip-tip baru saat mereka masuk dan memberi Anda kredit.