Apakah tugas atau cerita "hampir selesai" membenarkan perencanaan dengan kelebihan pada sprint berikutnya?

Kasus yang dimaksud:

Sprint hampir berakhir dan salah satu tim Scrum saya tidak menyelesaikan beberapa tugas. (Alasan untuk ini tidak penting untuk pertanyaan ini dan akan ditangani sesuai.) Salah satunya adalah kasus klasik "90% selesai" dengan jumlah poin cerita yang agak besar dan akan menjadi bagian dari sprint berikutnya - seperti di pertanyaan di sini .

Kami melakukan backlog grooming dan beberapa perkiraan awal untuk sprint berikutnya dan membahas bagaimana menangani tugas yang belum selesai ini. Sementara kita semua sepakat bahwa itu tidak akan dihitung terhadap kecepatan sprint ini, saya berpendapat bahwa kita tidak harus memperkirakan kembali kasus yang hampir lengkap dengan 1 bukannya lima poin cerita, karena saya ingin kompleksitas sebenarnya dan total pekerjaan dilakukan untuk menjadi masih terlihat. Dan melihat ke belakang estimasi itu benar. - Kami baru saja beralih ke (skala) tangkas dan beberapa tingkat manajemen perlu "melihat" bahwa kami masih lebih produktif dalam banyak hal daripada produk yang dikirim.

Jelas kecepatan dalam sprint ini akan turun, tetapi bagian yang "sudah selesai" yang ditransfer akan naik lagi sprint berikutnya.

Sejauh ini kita semua sepakat.

Tetapi karena tim kami agak kecil, empat poin adalah benjolan besar. Saya menyarankan bahwa untuk tugas ini saja dan dengan dokumentasi yang tepat kita dapat secara sadar merencanakan kelebihan empat poin.

Apakah itu pendekatan yang layak atau akan saya

• mengalami masalah yang belum saya antisipasi
• memberi contoh buruk dengan tim yang telah ditransfer menjadi gesit hanya beberapa bulan yang lalu?

Ketika sebuah cerita tidak selesai pada akhir sprint, maka poin-poin dari cerita tersebut tidak diperhitungkan terhadap kecepatan sprint itu dan cerita tersebut akan kembali ke tumpukan simpanan.

Jika selama perencanaan sprint berikutnya cerita dipilih untuk selesai, maka Anda dapat melakukan estimasi ulang cepat dari pekerjaan yang tersisa. Perkiraan ini hanya boleh digunakan selama sesi perencanaan untuk memastikan bahwa Anda tidak memuat sprint yang terlalu banyak dengan cerita-cerita dengan sejumlah besar poin di mana sebenarnya sangat sedikit pekerjaan yang perlu dilakukan untuk menyelesaikannya.
Di papan tulis (dan dalam kecepatan sprint baru), perkiraan awal cerita yang dibawa harus digunakan.

Cerita terbawa seperti itu adalah salah satu alasan mengapa kecepatan dapat bervariasi dari sprint ke sprint dan Anda harus menggunakan rata-rata untuk menghitung kapasitas tim ketika merencanakan sprint.

Jika cerita yang tidak selesai tidak diambil dalam sprint berikutnya, maka mungkin lebih baik untuk merencanakannya untuk nilai poin penuh ketika tidak diambil lagi, karena itu juga akan membutuhkan waktu untuk mendapatkan kecepatan yang lebih tinggi. lagi dengan keadaan saat tim berhenti mengerjakannya.

Jangan mencoba membuat kecepatan Anda terlihat lebih baik dari sebelumnya. Cara ke depan adalah dengan mengakui bahwa tugas itu tidak selesai Anda melebih-lebihkan apa yang bisa Anda lakukan dalam sprint dan gagal. Tapi itu adalah hidup, dan kesempatan untuk belajar.

Jadi 0 poin untuk tugas yang tidak lengkap.

Sedangkan untuk sprint baru, perkirakan pekerjaan yang dibutuhkan untuk menyelesaikan tugas dalam poin cerita dan menghitungnya sebagai tugas normal.

Anda khawatir bahwa kecepatan Anda akan terlihat terlalu rendah, Anda harus khawatir bahwa kecepatan Anda terlalu tinggi.

Memiliki kecepatan yang lebih tinggi daripada yang sebenarnya dapat Anda capai akan membuat Anda gagal lagi dan lagi.

Di tim kami, kami menggunakan beberapa cara berbeda untuk menangani cerita carry-over, tergantung pada keadaan.

• Ketika sprint hampir berakhir dan semua yang direncanakan sudah selesai (yang terjadi setiap sprint lainnya) maka kita mulai pada cerita selanjutnya di backlog (tapi jangan berkomitmen untuk rilis sprint). Ini disertakan secara otomatis dalam sprint berikutnya, dan untuk tujuan pelaporan semua poin cerita menuju ke sprint berikutnya.

• Ketika bagian dari cerita selesai sepenuhnya dan memiliki nilai bisnis sendiri, maka secara umum kami menyesuaikan kembali baik ruang lingkup dan perkiraan untuk cerita asli, dan bagian yang tersisa kembali ke jaminan simpanan.

• Jika perkiraan asli untuk cerita itu mati (yang kadang-kadang terjadi untuk cerita yang besar dan kompleks) kami mencoba belajar darinya :). Tidak ada poin cerita dalam sprint saat ini, perkirakan kembali keseluruhan cerita dalam perencanaan sprint berikutnya.

Ketika beberapa cerita terbawa dari sprint sebelumnya, maka dalam perencanaan sprint Anda tidak memulai dengan backlog sprint kosong. Tim memutuskan berapa banyak pekerjaan ekstra yang dapat mereka lakukan di atas itu. Misalnya: tim normal berkapasitas 100 SP / sprint, 20 poin sudah dalam proses, tim memutuskan untuk mengambil 90 SP baru, jadi Anda memiliki 110 SP di sprint di awal sprint.

Kelemahan utama dari pendekatan ini adalah bahwa laporan kecepatan tidak sebaik yang diinginkan beberapa manajer. Tetapi dalam jangka panjang semuanya mereda, dan dengan cara ini segala sesuatu yang berpotensi dapat dirilis disampaikan sedini mungkin, dan tim mendapatkan kredit untuk pekerjaan mereka.

Sedikit latar belakang: awalnya tim ini memiliki pendekatan yang sangat ketat untuk sprint tenggat waktu, sehingga mereka akan menolak untuk mengambil cerita yang lebih besar daripada yang bisa mereka selesaikan dalam minggu pertama (dari sprint 2 minggu), dan menggunakan yang kecil dan aman bekerja untuk bagian sprint yang tersisa. Meskipun ini menghasilkan tumpukan sprint kosong yang bagus di akhir sprint, ini memiliki terlalu banyak pengaruh pada pertanyaan 'apa yang akan kita kerjakan selanjutnya?'.

Ini bukan pertanyaan untuk jawaban yang mudah. Akan ada banyak pendapat tentang apa yang harus dilakukan, tetapi saya sarankan Anda mulai dengan mengidentifikasi berbagai kebutuhan yang harus Anda penuhi, dan datang dengan solusi berdasarkan itu. Contoh:

1. Sebuah tim "perlu" memahami bagaimana mereka bekerja, dan mengidentifikasi setiap peluang untuk perbaikan. Terkadang, mengubah poin cerita menutupi masalah yang harus diatasi.
2. Pemilik Produk "perlu" untuk dapat mengetahui berapa banyak poin cerita yang diperkirakan untuk suatu Fitur (seringkali ini dikumpulkan pada tingkat fitur) atau Rilis (AKA "PI" dalam SAFe-talk) dan mungkin meminta pembakaran di level fitur (atau PI) untuk menunjukkan kemajuan dalam memberikan MVP atau MMF. Mengubah poin cerita dapat memiringkan angka dan menyebabkan kebingungan.

Ada beberapa "pagar pengaman" untuk membantu memandu keputusan.

• Pekerjaan itu DILAKUKAN, atau tidak. Pekerjaan yang tidak lengkap tidak diperhitungkan dalam sprint di mana ia selesai.
• Cerita yang tidak lengkap harus diprioritaskan kembali (itu bukan "diberikan" bahwa mereka dibawa ke sprint berikutnya, mereka dapat kembali ke tumpukan atau ditinggalkan).

Yang sedang berkata, saya telah melihat banyak tim menangani ini dengan berbagai cara.

1. Jika cerita yang tidak lengkap masih valid dan disetujui oleh PO, seluruh cerita akan berlanjut ke sprint berikutnya. Apa yang tim ini sering lakukan adalah TAG kisah-kisah ini sebagai terbawa dan memperkirakan berapa banyak poin dari "pekerjaan yang tersisa" yang mereka wakili. Jadi, jika itu adalah cerita 13 poin, tetapi hanya memiliki 1 poin yang tersisa, mereka melakukan matematika untuk menyesuaikannya dengan mengurangi 12. Ini meninggalkan perkiraan awal untuk tujuan historis seperti yang Anda sarankan, sambil membantu tim mengetahui kapasitas mereka. Dalam hal ini, YA, Anda mungkin memiliki "lebih banyak poin" daripada "ambang batas" berbasis kapasitas Anda. Tetapi kecepatan bisa berubah sedikit, itu tidak ditulis di atas batu.
2. Saya telah melihat tim membagi cerita (Rally, misalnya, memiliki fungsionalitas yang sangat bagus untuk ini), dan menerapkan beberapa poin untuk bagian dari cerita yang "tetap" di sprint lama dan kemudian menerapkan poin ke bagian yang meneruskan. Pendekatan ini nyaman, tetapi itu melanggar prinsip bahwa "Selesai berarti DILAKUKAN", dan menyembunyikan fakta bahwa perkiraan mungkin buruk dan pekerjaan terus berjalan, sehingga kesempatan untuk belajar dan meningkatkan dapat hilang. (Ini bukan rekomendasi saya untuk alasan itu)
   3. Solusi terburuk yang saya lihat adalah mereka hanya menandai cerita lama DILAKUKAN, mungkin mereka mengurangi poin, mungkin tidak, dan kemudian mereka membuka cerita baru untuk pekerjaan yang tersisa (sering pengujian!). Ini adalah solusi jelek dengan standar apa pun, IMHO.

Apa yang akan saya fokuskan adalah ini: "Salah satunya adalah kasus klasik" 90% selesai "dengan sejumlah besar poin cerita" - kuncinya di sini adalah kisah BESAR! Ingat BERINVESTASI: cerita harus KECIL. Tim harus melihat baik kisah pemisah (lebih disukai) atau mengerumuni mereka. Tetapi lebih besar selalu berarti lebih banyak risiko, bahkan ketika dikerumuni.