Item sprint membutuhkan waktu lebih lama dari yang diharapkan selesai. Apa yang harus kita lakukan?

Apa yang harus kita lakukan jika item dalam scrum membutuhkan waktu lebih lama dari yang diharapkan? Saya menanyakan hal ini karena saya telah memperhatikan item yang sedang dikerjakan oleh pengembang untuk diselesaikan karena jauh lebih sulit dari yang diperkirakan pada awalnya.

Dalam situasi seperti itu sebaiknya kita

• hapus item dari sprint kembali ke katalog produk sehingga kita dapat memenuhi garis waktu sprint?
• pindah ke item sprint yang lebih mudah dan tinggalkan sprint yang bermasalah sampai akhir garis waktu
• membenarkan pada ulasan sprint mengapa item tidak dapat diselesaikan pada sprint saat ini kepada para pemangku kepentingan?

Bagaimana kita bisa menghindari situasi seperti itu di masa depan? Apakah karena kurangnya perencanaan di muka atau kami tidak berusaha untuk memecah item sprint menjadi item yang lebih kecil?

Dengan "item", saya kira maksud Anda "tugas".

Merencanakan optimisme dalam perangkat lunak sama tuanya dengan perangkat lunak itu sendiri. Hal yang baik tentang scrum adalah Anda akan segera menghadapinya dan membuat visibilitasnya: inilah mengapa kecepatan tim didasarkan pada data masa lalu dan bukan perkiraan di masa mendatang.

Untuk menyelesaikan cerita, Anda juga harus menyelesaikan tugas yang ternyata jauh lebih sulit daripada yang diantisipasi. Tidak ada alasan untuk menunda mereka. (Inilah sebabnya mengapa Definisi Selesai sangat penting). Jika itu berarti tim gagal cerita, maka terlalu buruk, Anda akan memiliki sesuatu untuk dibicarakan di retrospektif berikutnya. Velocity akan turun (menjadi lebih realistis) dan tim akan belajar membuat estimasi yang lebih baik, atau meninggalkan margin keamanan yang lebih besar untuk tugas-tugas yang tidak terduga. Pemilik produk akan mendapatkan pandangan yang lebih realistis tentang rencana rilisnya.

Apa yang harus kita lakukan jika item dalam scrum membutuhkan waktu lebih lama dari yang diharapkan?

Dengan asumsi bahwa menurut item yang Anda maksudkan adalah cerita, pada akhir sprint Anda biasanya memasukkannya kembali ke dalam tumpukan produk (dan kemungkinan merencanakannya untuk iterasi berikutnya). Tim skor poin nol untuk itu dalam iterasi saat ini.

Alternatif lain, jika ceritanya cukup besar, adalah mengirisnya secara vertikal . Misalnya, cerita "pencarian katalog produk", dapat dibagi menjadi "pencarian berdasarkan kategori" dan "pencarian teks lengkap", tetapi tidak dalam "form pencarian" dan "hasil pencarian".

Bagaimana kita bisa menghindari situasi seperti itu di masa depan?

Tidak ada jawaban langsung yang mudah untuk ini. Dalam scrum Anda melakukan sprint retrospektif setiap iterasi, di mana Anda biasanya mendiskusikan hal-hal semacam ini dengan tim. Ada banyak kemungkinan berbeda:

• Tim, atau beberapa anggota tim, mengalami minggu yang buruk
• Tim Anda menyalurkan item pekerjaan secara horizontal (mis. Backend-> frontend-> QA)
• Kisah-kisah itu terlalu besar karena kesalahan
• Tim "piring emas" cerita dengan menambahkan pekerjaan ekstra yang tidak sepenuhnya diperlukan untuk penyelesaian cerita.
• Kisah-kisahnya sangat besar, Anda perlu berlari lebih lama (tidak mungkin)
• Tim memperkirakan cerita secara tidak tepat (tidak jelas)
• Proyek ini memiliki banyak basis teknologi hutang / busuk kode dan kecepatan Anda terlalu rendah
• Anda tidak mengukur dan memperkirakan kapasitas sprint Anda dengan benar (atau tidak sama sekali).

dll. dll

Anda mengatakan Anda tidak akan menyelesaikannya, tapi itu tidak buruk, itu hanya data.

"Memenuhi garis waktu sprint" bukan tujuan. Tujuan Anda adalah untuk melengkapi cerita pengguna. Garis waktu hanyalah alat untuk membantu Anda mengukur dan mempelajari berapa banyak pekerjaan yang dapat Anda lakukan dalam sprint.

Jika Anda yakin tidak dapat menyelesaikan pekerjaan dalam sprint, salah satu solusinya adalah memindahkannya ke bagian bawah daftar prioritas dan mengerjakan cerita lain dalam sprint terlebih dahulu. Kemudian, dengan sisa waktu Anda dapat mulai mengerjakannya. Perkirakan kembali pekerjaan yang masuk ke sprint berikutnya dan selesaikan kemudian.

Pastikan dalam retrospektif Anda bahwa Anda membahas apa yang salah sehingga Anda dapat meningkatkan perkiraan Anda di masa depan.

Jika tugas lebih lama dari yang diharapkan, ini harus dibawa dalam retrospektif dan dibahas. Apakah ada bagian yang terlewatkan dalam analisis awal? Apakah ini sesuatu yang belum sering dilakukan oleh tim? Ada banyak alasan yang memungkinkan mengapa sesuatu bisa memakan waktu lebih lama dari perkiraan semula.

Tim harus berusaha menyelesaikan tugas sebaik mungkin dan kemudian dalam retrospektif mendiskusikan strategi tentang ini di masa depan. Jika tim cukup baru dalam menggunakan Scrum maka itu mungkin merupakan bagian dari menentukan kecepatan awal tim. Beberapa tim mungkin berpikir mereka dapat melakukan 20 poin dan beberapa tim mungkin melakukan 60 poin, intinya adalah seberapa konsisten jumlah poin yang sama dapat dilakukan setiap sprint.

Ini akan terjadi di masa depan karena setiap kali tim memiliki tugas-tugas baru yang belum dilakukan sebelum akan ada waktu yang dibutuhkan untuk menyelesaikan kekusutan membuat perkiraan. Ini adalah bagian dari proses pembelajaran yang seharusnya tidak terlalu mengejutkan.

Apa yang biasanya kita lakukan di perusahaan ketika tugas mulai lebih lama dari yang diharapkan adalah membaginya menjadi tugas yang lebih kecil.

Dengan begitu kami tidak menyalahkan pengembang karena terlalu lambat, tetapi kami juga mengakui bahwa tugas tersebut dirancang secara tidak benar.

Hal lain mungkin untuk menetapkan tugas kepada anggota lain Tim Pengembangan Anda untuk menghindari pengembang terlambat menggali dirinya ke dalam lubang. Dan jika tugasnya benar-benar kritis, beberapa XP bisa menjadi solusinya.