Saya baru-baru ini ditanya oleh seorang pengguna apakah saya memiliki cara untuk menganalisis kedewasaan tim dengan cara mereka menunjuk.
Hal ini membuat saya berpikir: hal-hal apa yang dilakukan (atau tidak dilakukan) oleh 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 tempat yang Anda inginkan.
Apa itu poin cerita?
Apa pun yang pernah Anda baca tentang scrum akan memberi tahu Anda: titik cerita mengukur kompleksitas, bukan waktu.
Ini adalah konsep yang sulit didapat; saya butuh 5 tahun untuk akhirnya memahami nuansa.
Membicarakan 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, itu harus cukup cepat. Mengapa semua ribut-ribut?
Mari kita kembali ke awal mengapa kita menggunakan Scrum, atau XP, atau semacamnya. Di masa lalu, kami biasa membuang waktu dalam rapat, membuat bagan Gantt, memberikan perkiraan, dan membuat proyeksi — mereka selalu salah! Jadi kami membuang banyak waktu untuk melakukan hal-hal yang tidak dapat dipercaya.
Kami diberi tahu bahwa poin cerita diciptakan karena “perkiraan waktu tidak akurat.” Ini benar, tetapi banyak orang berpikir ini menyiratkan bahwa poin cerita lebih akurat daripada perkiraan waktu. Itu tidak benar-benar terjadi. Perkiraan waktu tidak akurat, tetapi begitu juga poin cerita.
Poin cerita lebih baik karena lebih fleksibel. Mereka membuat proses memperkirakan dan memproyeksikan 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 pertama, Anda memiliki tumpukan cerita, tanpa perkiraan. Jadi tim membaca backlog dan memilih salah satu yang berukuran “sedang” — dan menetapkannya dalam poin sedang, 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 kompleks, cerita itu adalah 5. Jauh lebih sedikit, itu adalah 3.
Anda tahu sebuah cerita kurang lebih kompleks oleh beberapa faktor. Apakah itu memiliki beberapa yang tidak diketahui? Tidak diketahui membuatnya lebih kompleks. Apakah sulit untuk menguji? Itu lebih kompleks. Apakah itu bergantung pada API pihak ke-3? Itu lebih kompleks.
Setiap kali pengembang Anda berkata, “baik, saya perlu melakukan riset”, itu artinya itu lebih kompleks. Pilih nomor yang lebih besar dan lanjutkan.
Jangan samakan poin dengan waktu
Orang suka menyamakan poin cerita dengan waktu — ini salah. Mengapa? Sebagai 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? Dulunya bekerja untuk sehari, tapi sekarang hanya 3/4 dari 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 sama dengan waktu, dan tim Anda menjadi lebih cepat, Anda hanya perlu meningkatkan kecepatan sprint Anda. Kecepatan kami dulu adalah 90 poin per sprint tetapi sekarang kami memiliki server build baru, kami dapat melakukan 94 poin per sprint. Tidak perlu memperkirakan ulang seluruh backlog untuk membuat proyeksi akurat tentang masa depan.
Jika poin berhubungan dengan waktu, lalu mengapa menggunakan poin sama sekali? 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 kompleksitas:
Seorang pengembang berkata, “Saya tidak dapat menunjukkan sesuatu karena saya perlu melakukan lebih banyak penelitian.”
Tidak selalu, tetapi berkali-kali, ini adalah tanda penggunaan waktu. Mereka ingin menguraikan semua detailnya, sehingga mereka bisa menebak waktu yang dibutuhkan.
Seorang pengembang mengatakan, “ini adalah 3 jika saya mengerjakannya, tetapi 5 jika Jerry melakukannya”
Ini adalah pengukuran waktu yang lain. Apa yang mereka katakan adalah bahwa lebih sedikit waktu jika saya melakukannya. Tapi dengan poin cerita, kami tidak peduli siapa yang melakukannya. Kita tahu kecepatan rata-rata tim adalah 90 poin per sprint. Jerry mungkin menghabiskan lebih banyak waktu untuk tugas ini daripada yang saya lakukan, tetapi itu berarti saya sedang mengerjakan sesuatu yang lain. Jadi ikuti saja rata-ratanya dan jangan khawatir tentang spesifik siapa yang mungkin melakukan pekerjaan itu.
Jangan memperdebatkan perbedaan poin kecil
Kami tidak berdebat antara perbedaan poin kecil. Jika itu 1, 2, atau 3, itu tidak masalah. Jika banyak orang mengatakan 1, beberapa mengatakan 2, dan satu orang mengatakan 3… kita tetap memilih 3. Tidak ada waktu untuk membahas perbedaan 1 poin. Pilih yang besar dan bergerak maju.
Jangan terobsesi dengan perkiraan yang sempurna
Kami tidak khawatir tentang menjadi sempurna, kami berusaha untuk menjadi 80% benar. Ketika tim baru mengenal scrum, banyak penekanan diberikan pada perkiraan yang sempurna, karena, sebelum scrum, kami selalu membutuhkan perkiraan yang sempurna. Terkadang sebuah organisasi bahkan menuntut tim scrum memiliki perkiraan yang sempurna. Ini tidak baik dan seorang Scrum Master perlu bekerja keras untuk mengatasinya. Setelah tim pengembangan berada di tempat yang aman, mereka dapat dengan cepat menetapkan poin dan mulai bekerja. Karena menyelesaikan pekerjaan adalah nama sebenarnya dari permainan. Poin hanya ada untuk membantu Anda melihat ke masa depan dan memproyeksikan kapan beberapa tonggak akan tercapai. Akurasi 80% adalah sweet spot. Lebih baik dari itu dan Anda membuang terlalu banyak waktu dalam perencanaan. Lebih buruk dari itu dan seluruh perusahaan tidak dapat merencanakan secara akurat.
Jangan menyerah pada tekanan untuk mengubah sejumlah poin
Mungkin sulit ketika Anda memiliki PO yang menuntut, “apakah ini benar-benar angka 5, bukankah seharusnya angka 3?” Atau beberapa eksekutif berkata, “mengapa Tim A menyelesaikan 100 poin, tetapi Tim B hanya mencapai 75?”
Tim yang kurang matang akan hancur di bawah tekanan. Mereka akan mencoba menyelesaikan 5 dalam waktu 3 dan pada akhirnya itu tidak akan berhasil. Ini mungkin langsung terlihat karena mereka tidak menyelesaikan seluruh sprint. Atau mungkin muncul di jalan karena utang 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 mengisi nomor mereka. Mereka tidak akan 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 utang teknis yang akan dihasilkan.
Dan jika seorang eksekutif menyiratkan bahwa produktivitas mereka lebih rendah, mereka akan menggalinya. Mungkin eksekutif membandingkan apel dengan jeruk dan sampai pada kesimpulan yang salah? Atau mungkin produktivitas tim yang matang justru lebih rendah? Saya mengharapkan tim yang matang untuk menggali, mencari tahu apa yang salah (jika ada), dan membuat perubahan yang sesuai untuk ditingkatkan. Mereka tidak akan hanya mengisi nomor mereka untuk memenuhi kekuatan; yang tidak membantu siapa pun.
Bagaimana denganmu? Pernahkah Anda mengalami sesuatu yang membedakan tim yang matang? Tolong bagikan; kami akan memperbarui artikel ini dengan kiat-kiat baru saat mereka masuk dan memberi Anda kredit.
