Apa yang harus dilakukan ketika sprint selesai lebih awal?

Apa yang harus dilakukan ketika sprint selesai lebih awal?

Saat ini tim Scrum kami menyusun cerita dari tumpukan, jika sprint selesai lebih awal.

Apa yang terjadi dengan cerita yang diambil dari jaminan simpanan? Apakah cerita akan ditambahkan ke Sprint saat ini? Jika ya, bagaimana jika cerita-cerita ini tidak akan selesai tepat waktu. Apakah Sprint gagal?

Bawa sesuatu dari tumpukan proyek ke sprint (setelah diskusi dengan scrum master dan pemilik proyek).

Ukuran barang yang Anda lakukan akan tergantung pada berapa banyak waktu yang Anda miliki. Jika tidak ada yang cukup kecil, buatlah sub tugas dari tugas yang lebih besar untuk memulainya (yaitu melakukan beberapa pekerjaan pendahuluan).

Atau buat beberapa tugas yang membuat basis kode lebih baik. Saya belum pernah melihat basis kode yang tidak dapat diperbaiki dalam beberapa cara. Tinjau beberapa kode tambahkan lebih banyak unit test dll.

Mengerjakan item sprint backlog di masa depan tampaknya merupakan hal yang biasa dilakukan, yang masuk akal jika item sprint backlog Anda cukup kecil dan didefinisikan dengan jelas. Namun, menumpuk item yang dapat menempatkan kode "selesai" ke dalam status "tidak lagi selesai" harus dihindari.

Jika sprint benar-benar selesai, tandai, siapkan untuk pengiriman, kirim, dan masukkan repositori kode sumber Anda ke dalam status "sprint berikutnya" sehingga tidak ada risiko bahwa perubahan sprint yang terlambat akan membuat pengiriman berisiko.

Bagi kami, Sprint tidak pernah berakhir lebih awal. Kami hanya meningkatkan kecepatan kami atau menyelesaikan masalah dengan cara yang membuat kami menyelesaikan lebih banyak pekerjaan dalam sprint.

Mengatakan bahwa kami selalu memiliki tumpukan item yang diprioritaskan menurut kepentingan pemilik produk kami. Ketika tim mana pun dapat memasukkan lebih banyak pekerjaan ke dalam sprint, sangat mudah bagi mereka untuk melihat apa yang harus dilakukan selanjutnya dalam daftar yang akan cocok secara positif dengan sisa waktu sprint karena kecepatan mereka.

Ini menghindari segala downtime oleh kelompok menunggu diskusi dengan Pemilik Produk / Scrum Master tentang apa yang harus dilakukan selanjutnya. Pemilik Produk dan Master Scrum kami tetap menjadi yang teratas dalam daftar ini sehingga selalu ada lebih banyak pekerjaan yang menunggu untuk dimasukkan ke dalam sprint berikutnya (atau yang sekarang jika waktu diizinkan.)

Apa yang dilakukan tim saya adalah menarik tugas dari tumpukan yang cukup kecil untuk diselesaikan sehubungan dengan seberapa awal kami selesai. Jika kami selesai dengan itu , kami memberi waktu bagi tim QA kami untuk mengejar pengujian mereka, dan pengembang mendapatkan "hari bebas" - kami dapat menggunakan ini untuk melihat masalah lain yang tidak terkait dengan sprint saat ini, topik yang kami inginkan untuk meneliti, mengkonfigurasi / mengkonfigurasi ulang lingkungan kita, dll.

Jangan menaruh banyak pekerjaan hanya karena Anda selesai lebih awal. Berpegang teguh pada apa yang telah dilakukan oleh tim Anda dalam sprint ini, dan jika pekerjaan ekstra selesai, itu merupakan nilai tambah yang luar biasa.

Saya mendorong slack untuk digunakan untuk perbaikan pribadi. Tentu, tarik cerita dari tumpukan, tapi pastikan Anda meluangkan waktu untuk diri sendiri: belajar bahasa baru, berlatih kerajinan tangan Anda dengan kata, refactor beberapa hal, tweak, memperbaiki atau menulis alat baru untuk membantu Anda keluar, pergi dan berbicara kepada pemangku kepentingan, kolega atau klien, cari tahu apa yang dilakukan tim QA Anda, luangkan waktu untuk memahami bagaimana proses UX Anda bekerja.

Ada banyak hal yang dapat Anda lakukan yang akan memberikan nilai bagi bisnis Anda dan diri Anda DAN meningkatkan kecepatan Anda atau jumlah nilai kualitas yang Anda berikan yang tidak melibatkan menarik sesuatu dari tumpukan, coba yang pertama.