Ada beberapa aspek dalam hal ini, tetapi pada tingkat tinggi, ya - PM pasti ingin memahami dengan jelas mengapa pekerjaan yang direncanakan belum selesai. Namun, ini harus diangkat (dan diselesaikan) dalam retrospektif. Dari sisi dev, ada banyak faktor yang dapat menyebabkan kegagalan sprint.
Beberapa hal yang mungkin ingin Anda pertimbangkan:
Terlalu banyak dalam sprint
Jika Anda secara teratur melakukan terlalu banyak pekerjaan, maka sprint akan gagal. Kecepatan sprint harus dilacak dari waktu ke waktu untuk mengetahui berapa jumlah titik (atau hari) yang optimal.
Alokasi sumber daya
Pastikan bahwa perencanaan sprint mencukupi untuk kegiatan non-pengembangan seperti upacara, liburan, pelatihan, admin, dukungan, dan proyek lainnya, dll. Secara otomatis dengan asumsi setiap orang mengembangkan setiap menit setiap jam mereka secara fisik di kantor tidak praktis dan akan segera menempatkan Anda pada kaki belakang dari mulai.
Perkirakan variasi
Anda sedang melakukan penyempurnaan, tetapi adakah tugas-tugas tertentu yang selalu dikuasai? Biasanya ini karena persyaratan yang hilang atau tidak jelas. Jika persyaratannya tidak jelas, cerita seharusnya tidak membuatnya menjadi sprint kecuali jika sudah disempurnakan atau spike telah direncanakan.
Kecepatan
Jika kecepatannya dilacak dengan benar, jumlah sebenarnya cerita harus menjadi jelas. Itu tidak berarti mereka akan selalu selesai tepat waktu, tetapi itu akan membuat banyak hal lebih mudah.
Niat baik
Pada proyek apa pun, niat baik terbatas. Jika Anda terus-menerus bekerja selama berjam-jam untuk memberikan, semangat kerja akan menderita dan devs akan kelelahan - ini adalah kegagalan manajemen proyek . Seperti yang sudah saya jelaskan, pastikan perencanaan sprint hanya menjadwalkan sejumlah cerita realistis menggunakan kecepatan dan paku untuk membantu Anda sepanjang jalan.
Sepatu berduri
Jika suatu item disempurnakan dengan buruk atau hanya terbuat dari wol, jangan takut untuk melakukan spike untuk memberikan perkiraan yang lebih baik untuk sprint selanjutnya. Ya, beberapa orang hanya buruk dalam estimasi tetapi sebagian besar waktu, fakta lengkap hanya tidak diketahui pada saat itu. Idealnya, ini seharusnya sudah tercakup dalam penyempurnaan atau diambil lebih awal oleh PO, tetapi kadang-kadang mereka dapat lolos dari sprint. Pengembang harus mendorong kembali pada hard ini karena ini dapat dengan mudah torpedo sprint yang jika tidak berjalan dengan baik.