Haruskah Tim Anda Mengklaim Tugas dalam Perencanaan Sprint?

Perencanaan sprint biasanya merupakan proses yang rajin dan produktif. Tim menyempurnakan backlog, menetapkan kecepatan target, memilih cerita pengguna untuk sprint mendatang, memperkirakan upaya, dan menentukan tugas. Dilakukan dengan benar, tim meninggalkan perencanaan dengan tujuan sprint yang jelas dan rencana sprint yang bersih. Terasa enak, bukan?

Terlepas dari semua perencanaan ini, pengembang sering kali meninggalkan perencanaan tanpa tugas yang ditugaskan kepada mereka – dan itu bisa menjadi hal yang baik.

Untuk tim scrum yang lebih baru, menugaskan tugas selama perencanaan sprint bertindak sebagai semacam jaring pengaman – meyakinkan untuk mengetahui siapa yang bertanggung jawab atas item mana, dan menugaskan setiap tugas dapat membantu meredakan kekhawatiran bahwa cerita akan tertinggal. Meskipun pendekatan ini meningkatkan akuntabilitas individu, pendekatan ini mengorbankan akuntabilitas tim. Bagaimanapun, tim berkomitmen untuk cerita tertentu bersama-sama; mereka harus berbagi tanggung jawab untuk mengklaim dan menyelesaikan tugas selama sprint.

Meskipun mengklaim tugas setelah perencanaan sprint direkomendasikan, setiap tim harus memutuskan cara terbaik untuk mengadopsi tugas. Lihat beberapa cara tim Anda dapat meninggalkan perencanaan sprint dengan rencana permainan terbaik.

Santai saja
Menginginkan perasaan aman yang datang dengan sprint yang ditugaskan sepenuhnya dapat dimengerti, tetapi ada biayanya. Sangat mudah bagi tim untuk terkunci dalam hierarki pengembangan tertentu, sangat dekat dengan pola pikir air terjun. Membuat Pengembang A selalu bertanggung jawab untuk pengujian unit sementara Pengembang B hanya bekerja pada pembuatan logika database membuat tim jauh lebih fleksibel. Pengembang Anda mungkin memang memiliki kompetensi inti (oleh karena itu keseluruhan tim lintas fungsi), dan tidak ada yang salah dengan penetapan tugas berdasarkan keahlian – berhati-hatilah. Pepatah tangkas “menanggapi perubahan daripada mengikuti rencana” harus memandu tim Anda di sini.

Meskipun demikian, tim baru mungkin membutuhkan roda pelatihan untuk memulai. Mike Cohn dari Mountain Goat Software merekomendasikan untuk mempertimbangkan penugasan penuh tugas untuk lima sprint pertama tim. Untuk beberapa tugas berikutnya, lanjutkan dengan menetapkan 50% tugas, lalu 25%, dan akhirnya 0%. Transisi bertahap ini dapat membantu tim merasa lebih nyaman dengan kemampuan dan komitmen satu sama lain, dan dapat menyampaikan gagasan bahwa tim memiliki sprint backlog.

Tetapkan Tugas Tunggal
Tentu saja, banyak tim suka meninggalkan perencanaan sprint dan langsung mulai bekerja; mengklaim tugas bisa terasa seperti penghalang yang tidak perlu. Beberapa tim mengatasi masalah ini dengan mendorong setiap pengembang untuk memilih satu tugas dari setiap cerita pada perencanaan sprint, membiarkan sisanya tidak ditugaskan. Pendekatan ini membantu tim menjadi jauh lebih fleksibel dan mendorong akuntabilitas tim. Jika tugas berakhir lebih lama dari yang diharapkan, Anda tidak akan memiliki pengembang yang tiba-tiba berada di bawah air selama sisa sprint. Hal ini juga mengurangi keengganan bagi pengembang untuk melompat ke tugas yang mungkin bukan “milik” mereka. Semuanya menjadi milik tim, dan tim bertanggung jawab untuk menyelesaikan pekerjaan yang diramalkan dalam perencanaan.

Jadi apa yang Anda pikirkan? Apakah tim Anda membiarkan perencanaan sprint siap beraksi, atau apakah Anda lebih suka macet lambat?

Kredit Foto