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

8

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?

— Stephie
sumber

6

90% pertama dari tugas membutuhkan 90% dari waktu. Sisanya 10% dari tugas mengambil 90% lainnya dari waktu.

— Brad Thomas

5

"beberapa level manajemen perlu" melihat "bahwa kita masih produktif dalam lebih banyak cara daripada produk yang dikirim." - aduh. Sangat disayangkan.

— Bryan Oakley

6

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.

— Bart van Ingen Schenau
sumber

Maaf, tapi itu salah. Ketika PBI tidak dilakukan pada akhir sprint, PBI akan diestimasikan ulang untuk jumlah pekerjaan yang tersisa dan estimasi baru adalah yang menentukan kecepatan Anda untuk sprint berikutnya, bukan estimasi awal. Jika Anda memiliki 8, tetapi hanya menyelesaikan 75% dari itu, jadi sekarang pada dasarnya 2, bahwa 2 adalah upaya yang Anda keluarkan dalam sprint untuk menyelesaikannya, bukan 8. Dengan menggunakan nilai asli, Anda ulang kecepatan Anda dengan poin cerita 6 tambahan di sini. Titik kecepatan adalah untuk melihat apa yang bisa ditangani oleh tim Anda, jadi itu hanya mencerminkan pekerjaan yang dilakukan dalam sprint.

— Chris Pratt

@ ChrisPratt: Pengukuran kecepatan harus rata-rata lebih dari beberapa sprint tepatnya untuk rata-rata efek dari pekerjaan yang belum selesai dibawa ke sprint lain. Dengan asumsi bahwa Anda tidak mengusulkan untuk menghitung 6 poin dalam sprint yang tidak menyelesaikan cerita, Anda akan kehilangan 6 poin usaha dalam statistik lain yang didasarkan pada estimasi. Juga, jika Anda melihat kembali cerita itu nanti untuk referensi dalam perkiraan lain, Anda akan salah merepresentasikan kompleksitasnya.

— Bart van Ingen Schenau

Velocity adalah ukuran berapa banyak poin cerita yang dilakukan. Tidak ada kredit parsial. Jika Anda memiliki cerita 8 poin dan Anda hanya menyelesaikan 3/4, Anda tidak menyelesaikannya. 8 poin itu hilang. Kisah ini kemudian diubah ukurannya untuk pekerjaan yang tersisa, dan kembali di tumpukan Anda, di mana Anda mungkin atau mungkin tidak bekerja di sprint berikutnya. Ini mengempiskan kecepatan Anda, tetapi itulah intinya. Anda tidak dapat menyelesaikan pekerjaan, jadi kecepatan Anda harus turun.

— Chris Pratt

6

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.

— Bengkok
sumber

Bukankah ini mengecilkan pekerjaan yang sudah dilakukan?

— Brad Thomas

Intinya adalah bahwa kemungkinan besar ini bukan pencilan, jarang. Tetapi jika itu adalah outlier dan sisa sprint memiliki kecepatan lebih tinggi maka kapur sprint ini hingga hal-hal yang terjadi. Tetapi untuk mengetahui bahwa itu adalah pencilan, Anda harus mengetahui kebenarannya. Tugas tidak dilakukan kecuali memenuhi definisi selesai dan tidak.

— Bent

Saya tidak bertanya-tanya tentang bagian "belum selesai", hanya tentang bagaimana merencanakan dengan bagian yang sudah selesai. Dan demi argumen, mari kita asumsikan alasan untuk tidak menyelesaikan sepenuhnya sah, tidak ada tim dalam bentuk atau bentuk yang bertanggung jawab atas dan perencanaan yang benar.

— Stephie

4

@Stephie Tidak ada alasan "sah" dan "tidak sah" untuk cerita tidak lengkap. Yang lebih relevan adalah apakah alasannya berulang dan / atau dapat ditindaklanjuti. Jika alasannya tidak berulang maka penurunan kecepatan Anda harus singkat. Jika berulang, maka Anda benar-benar hanya memiliki kecepatan yang lebih rendah. Either way, "kompensasi" tidak perlu.

— Derek Elkins meninggalkan SE

Ya, ini mengecilkan pekerjaan yang dilakukan, tetapi itulah yang Anda inginkan. Orang-orang tampaknya ingin mengukur kecepatan, seolah-olah itu didorong lebih tinggi dan lebih tinggi. Bukan itu intinya sama sekali. Velocity adalah ukuran seberapa banyak pekerjaan yang dapat dilakukan tim Anda dengan kecepatan normal selama sprint apa pun. Jika Anda overdid, dan tidak menyelesaikan semua poin cerita Anda di sprint Anda, maka itu berarti kecepatan Anda melacak terlalu tinggi. Ini bukan tentang mencari hak yang baik atau menyombongkan diri; ini tentang bisa mengukur secara akurat seberapa banyak yang dapat dilakukan tim.

— Chris Pratt

1

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?'.

— Marielle
sumber

0

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:

Sebuah tim "perlu" memahami bagaimana mereka bekerja, dan mengidentifikasi setiap peluang untuk perbaikan. Terkadang, mengubah poin cerita menutupi masalah yang harus diatasi.
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.

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.
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)
1. 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.

— Curtis Reed
sumber