Scrum - cara membawa Kisah Pengguna yang telah lengkap sebagian ke Sprint berikutnya tanpa mengungkung backlog

Kami menggunakan Scrum dan kadang-kadang menemukan bahwa kami tidak bisa menyelesaikan Kisah Pengguna dalam sprint yang direncanakan. Dengan gaya Scrum sejati, kami tetap mengirimkan perangkat lunak dan mempertimbangkan untuk memasukkan Kisah Pengguna dalam sprint berikutnya selama sesi Perencanaan Sprint berikutnya. Mengingat bahwa Kisah Pengguna yang kami bawa sebagian sudah selesai, bagaimana kami memperkirakannya dengan benar di sesi Perencanaan Sprint berikutnya? Kami telah mempertimbangkan:

a) Menyesuaikan jumlah Story Points ke bawah untuk mencerminkan hanya pekerjaan yang tersisa untuk menyelesaikan Story Pengguna. Sayangnya ini akan mengacaukan melaporkan Product Backlog.

b) Tutup Story Pengguna yang sebagian-selesai dan angkat yang baru untuk mengimplementasikan sisa fitur itu, yang akan memiliki Poin Cerita lebih sedikit. Ini akan memengaruhi kemampuan kita untuk secara retrospektif melihat apa yang tidak kita selesaikan dalam sprint itu dan sepertinya memakan waktu.

c) Jangan repot-repot dengan a atau b dan terus menebak selama Perencanaan Sprint mengatakan hal-hal seperti "Ya, User Story mungkin adalah poin cerita X, tapi saya tahu itu sudah selesai, jadi saya yakin kita bisa menyesuaikannya."

Di tim saya saat ini kami melakukannya c).

Kecepatan harus memperhitungkan hal-hal yang benar-benar diselesaikan oleh tim dalam sprint. Sesuatu yang tidak terkirim tidak memiliki nilai bagi pelanggan, jadi kami tidak menghitung poin untuk itu, semuanya atau tidak sama sekali.

Jadi kami menggeser keseluruhan cerita yang belum selesai ke sprint berikutnya dan semua poin ceritanya akan ditambahkan ke kecepatan sprint berikutnya. Kecepatan bahkan keluar seiring waktu dan kami mengambil rata-rata dari beberapa sprint sebelumnya sebagai referensi untuk menentukan perkiraan kecepatan di masa depan.

Opsi A adalah tindakan yang umum direkomendasikan. Anda tidak memberikan poin untuk penyelesaian cerita untuk sprint sebelumnya dan untuk memindahkan cerita kembali ke tumpukan produk, di mana itu diprioritaskan ulang. Anda menghitung kecepatan Anda (dan metrik lainnya) berdasarkan cerita pengguna yang telah selesai dan nilai tambah. Ketika Anda mulai merencanakan sprint berikutnya, Anda mengambil cerita prioritas tertinggi berdasarkan nilainya (yang mungkin atau mungkin tidak termasuk cerita yang belum selesai, jika prioritas bisnis telah berubah). Saat Anda memperkirakan cerita, sertakan pekerjaan yang telah dilakukan ketika memperhitungkan jumlah poin baru untuk cerita tersebut.

Tentu saja, opsi alternatif (dan preferensi saya) akan menggunakan perkiraan jumlah poin cerita yang asli, yang merupakan sesuatu yang telah saya lakukan di masa lalu. Ini membuat asumsi bahwa perkiraan Anda bagus dan beralasan, tetapi Anda terlalu banyak mengurangi pekerjaan untuk sprint (misalnya - cerita sebenarnya bernilai 3 poin, tetapi masalahnya terletak pada fakta bahwa Anda menarik 15 poin cerita saat Anda seharusnya hanya menarik 13). Ini asumsi yang berpotensi berbahaya jika Anda tidak yakin dengan kemampuan Anda untuk melakukan estimasi, tetapi itu mungkin bekerja berdasarkan tim dan proses Anda.

Namun, Anda menyebutkan bahwa ini akan "mengacaukan pelaporan Product Backlog". Product Backlog harus dinamis, dengan urutan dan estimasi setiap cerita berubah karena lebih banyak dipahami tentang teknologi, sistem, persyaratan, dan pelanggan. Biasanya, apa yang akan dilaporkan dari Product Backlog adalah jumlah cerita pengguna dan jumlah total poin cerita. Ini harus diharapkan untuk berubah ketika prioritas berubah, persyaratan baru ditambahkan, persyaratan tidak valid dihapus, dan lebih banyak informasi dipelajari.

Memikirkan terlalu banyak tentang ini membuatnya tampak lebih rumit daripada sebenarnya ... Ini sebenarnya cukup sederhana:

Opsi C

Cerita yang tidak lengkap kembali ke tumpukan produk, tanpa poin yang diubah. Ketika merencanakan sprint berikutnya dan apa yang bisa dilakukan, diskusi harus mencakup fakta bahwa sebagian besar pekerjaan sudah selesai. Jika tim memutuskan bahwa mereka dapat memasukkannya ke dalam sprint, maka masuk, dengan jumlah poin semula. Jika tidak, ia tetap berada di backlog. Selesai. Poin diberikan ke sprint di mana cerita itu selesai.

Jika ini membantu, Anda dapat melacak metrik "sisa pekerjaan" yang terpisah untuk setiap cerita pengguna, sehingga jika, pada akhir sprint, cerita tersebut tidak lengkap, perkiraan sisa pekerjaan dapat dicatat pada cerita dan diperhitungkan saat merencanakan inklusi dalam sprint berikutnya. Tetapi meskipun begitu, jangan mengubah nilai poin cerita asli.

Jika alat pelaporan Anda tidak dapat menangani opsi A secara akurat maka saya akan menggunakan opsi B kecuali jika Anda tidak memiliki harapan untuk menggunakan metrik Anda.

Dalam beberapa kasus Anda dapat melakukan opsi B DAN tidak condong apa yang ditutup berarti dengan mempersempit ruang lingkup tugas lama yang akan ditutup dan hanya membuat tugas baru untuk ruang lingkup yang tersisa. Ini membuat sejarah lebih masuk akal secara semantik dan biasanya menunjukkan tempat-tempat di mana Anda seharusnya mempertimbangkan untuk memecah tugas lebih jauh. Kadang-kadang ini tidak mungkin atau logis dan Anda hanya memiliki tugas yang sebesar itu atau berjalan ke tingkat masalah itu.

sunting: Ini mengasumsikan (karena saya percaya OP berasumsi) bahwa pekerjaan yang hampir lengkap belum diutamakan dan bahwa mendapatkan hasil dari upaya sebelumnya membuatnya cukup tinggi dalam daftar untuk terus bekerja. Saya tahu beberapa toko tidak melakukan ini, tetapi sebagian besar tempat saya telah bekerja menganggap menyelesaikan tugas sisa hampir lengkap menjadi cukup berharga untuk melanjutkan sederhana kecuali ada sesuatu yang berubah secara dramatis. Hukuman untuk mengubah konteks seringkali tidak layak untuk diubah urutannya.

Mengingat bahwa Kisah Pengguna yang kami bawa sebagian sudah selesai, bagaimana kami memperkirakannya dengan benar di sesi Perencanaan Sprint berikutnya?

Saya tidak berpikir opsi A sampai C itu baik, terutama karena yang (saya pikir) harus paling penting mengenai kecepatan tim adalah kecepatan rata - rata dan bukan apakah kecepatan setiap sprint naik atau turun.

Ketika cerita pengguna didefinisikan, itu harus memiliki kriteria penerimaan. Jika sesuatu dalam kriteria penerimaan tidak dilakukan, maka tim sama sekali tidak mendapatkan poin. Jika cerita selesai dilakukan (yaitu dikode, diuji, dan diterima oleh PO) maka tim mendapatkan semua poin.

Ini bekerja dengan baik ketika tim fokus pada kecepatan rata - rata daripada kecepatan sprint yang diberikan.

Seperti M. Cohn dalam bukunya, saya cenderung memiliki preferensi untuk skenario semua-atau-tidak sama sekali. Lagi pula, mencoba memperkirakan apakah Anda telah menyelesaikan 5 poin dari cerita 8 poin, atau mungkin hanya 6 atau 7 yang akhirnya akan menjadi permainan tebak-tebakan lain ... dan jangan lupa bahwa Anda sudah mendapatkan inisial memperkirakan jauh. Mungkin lebih baik untuk hanya pergi dengan metode paling sederhana dan ketika mendapatkan semua poin setelah itu benar-benar selesai.

Mengutip M. Cohn dari bukunya¹ (penekanan saya):

Saya umumnya mendukung sikap semua-atau-tidak sama sekali untuk menghitung kecepatan: jika sebuah cerita dilakukan (diberi kode, diuji, dan diterima oleh pemilik produk), tim mendapatkan semua poin, tetapi jika ada sesuatu dalam cerita tersebut tidak selesai, mereka tidak mendapat apa-apa. Pada akhir iterasi, ini adalah kasus termudah untuk dinilai: Jika semuanya dilakukan, mereka mendapatkan semua poin; jika ada yang hilang, mereka tidak mendapat poin. Jika tim cenderung mengambil bagian cerita yang tersisa di iterasi berikutnya, ini akan berhasil. Kecepatan mereka dalam iterasi pertama sedikit lebih rendah dari yang diharapkan karena mereka tidak mendapat pujian karena menyelesaikan sebagian cerita. Namun dalam iterasi kedua, kecepatan mereka akan lebih tinggi dari yang diharapkan karena mereka akan mendapatkan semua poin, meskipun beberapa pekerjaan telah selesai sebelum dimulainya iterasi.Ini bekerja dengan baik selama semua orang ingat bahwa kami lebih tertarik pada kecepatan rata-rata tim dari waktu ke waktu, bukan pada apakah kecepatan melonjak naik atau turun dalam iterasi yang diberikan.

Est Estimasi dan Perencanaan Agile, Estimasi Ulang Cerita yang Selesai Sebagian, hal.66

Tim saya sebelumnya telah mencoba untuk menetapkan poin parsial, meskipun ada beberapa keberatan, dan saya pikir itu tidak berhasil sama sekali. (Kami tidak melakukannya lagi ... go figure) Ini terutama terjadi karena cerita seharusnya diperkirakan sebagai tim , namun jika hanya satu orang yang mengerjakannya, akan lebih sulit bagi tim untuk tahu berapa banyak individu telah benar-benar selesai. Agile lebih tertarik pada kecepatan rata-rata tim daripada pada seberapa "bagus" penampilan sprint tertentu.

Yang sedang berkata, penulis tidak menyebutkan bahwa menugaskan poin parsial dapat dipertimbangkan jika tim tidak mungkin untuk menangani pekerjaan yang tersisa di iterasi berikutnya. Dalam hal ini, tim akan memperkirakan pekerjaan yang tersisa dan memecahnya menjadi cerita pengguna baru dengan ukuran apa pun yang mereka rasa seharusnya mereka miliki. Seperti yang penulis sebutkan²:

Estimasi gabungan tidak perlu sama dengan estimasi asli ...

² Ditto, hal.66

Rekomendasi yang lebih baik bagi tim adalah memecah cerita menjadi ukuran yang cukup kecil untuk menghindari masalah semacam ini³:

Namun, dua solusi terbaik untuk mengalokasikan poin untuk cerita yang tidak lengkap adalah tidak memiliki cerita yang tidak lengkap dan menggunakan cerita yang cukup kecil sehingga kredit parsial tidak menjadi masalah.

³ Ditto, hal.67

Semoga ini membantu.

Saya terkejut sepertinya tidak ada jawaban langsung untuk ini. Saya mengharapkan paduan suara "opsi D, dummy"!

Karena kami sepertinya tidak melewatkan sesuatu yang jelas, kami pikir ini adalah salah satu keputusan yang perlu dibuat oleh masing-masing tim berdasarkan pada bagaimana mereka ingin bekerja dan metrik apa yang paling penting bagi mereka.

Kami memutuskan bahwa menyimpan catatan akurat tentang cerita pengguna yang kami laksanakan sangat penting, karena ini membentuk dasar untuk pengujian kami, dokumentasi dukungan, dan catatan rilis - yang mengesampingkan opsi B.

Selanjutnya kami memperkirakan bahwa dapat melakukan perencanaan sprint secara akurat sangat penting - yang mengesampingkan opsi C.

Karena itu kami telah menyimpulkan bahwa opsi A tepat untuk kami. Kami akan memperkirakan kembali poin cerita untuk setiap cerita yang kami selesaikan sebagian dalam sprint agar kami dapat merencanakannya dengan benar di sprint berikutnya. Seiring waktu, jaminan simpanan produk akan sedikit melaporkan jumlah poin cerita yang telah kami terapkan, tetapi ini akan menjadi masalah yang lebih kecil daripada opsi lain mana pun dan mungkin dapat diselesaikan dengan mengubah penyimpanan dan pelaporan catatan kami.

Kami melacak waktu yang dihabiskan dalam iterasi sprint untuk tujuan kapitalisasi, (jam dibakar pada tugas yang terkait dengan cerita pengguna), dan memindahkan cerita pengguna runcing bersama jika tujuan PO adalah untuk terus mengangkutnya selama sprint berikutnya, meninggalkan poin yang sama.

Jika tujuan PO adalah untuk memindahkan sesuatu yang lain di tempatnya, maka kami hanya akan memasukkan cerita yang belum selesai ke dalam tumpukan dan melakukan apa pun yang mereka inginkan. Meninggalkan perkiraan awal poin adalah rekomendasi saya, karena jika Anda memiliki kebiasaan menggigit lebih dari yang Anda bisa mengunyah, setiap sprint, Anda akan "menyelesaikan" poin cerita dalam sprint yang tidak sepenuhnya dilakukan dan dibersihkan - barang yang diuji.

Jika Anda memang ingin meninggalkan sesuatu di sprint, runcing, atau Anda harus mengirim, saya pikir Anda akan menentukan titik irisan dalam cerita asli, yang Anda lakukan mencapai titik selesai, dan melakukan bagian yang lebih kecil untuk iterasi Anda. Kemudian sisanya dapat diarahkan kembali, dan jatuh ke tumpukan. Itu akan menjadi peluang untuk memperkirakan kembali karena Anda setuju dengan tim Anda untuk membagi cerita menjadi beberapa irisan.

Pertanyaan pertama yang diajukan adalah Apa Arti Sebuah Titik Cerita? Jika Anda mendefinisikan titik cerita sebagai "Berapa banyak rekayasa pekerjaan yang dilakukan", maka jawaban apa pun akan dilakukan. Namun, jika Anda mendefinisikan titik cerita sebagai "Berapa nilai yang dikirimkan ke bisnis", maka menjadi penting untuk tidak memberikan kredit sampai sebuah cerita selesai 100%, diterima, dan disampaikan 100%. Mengubah poin cerita setelah sprint berdasarkan apa yang telah diselesaikan hanya akan menyembunyikan masalah sebenarnya: a) tidak ada pemahaman yang jelas tentang cerita, b) cerita itu terlalu kasar, c) cerita tersebut tidak memiliki kriteria penerimaan yang dapat diukur, d ) bukan pemahaman yang cukup mendalam tentang tugas atau ketergantungan untuk menyelesaikan cerita, e) mengecilkan upaya untuk menguji cerita, f) menarik terlalu banyak poin cerita, atau g) ... masukkan alasan Anda di sini ...

Tujuan tangkas adalah untuk menjadi fleksibel sambil diprediksi. Menurut pendapat saya, cara terbaik untuk konsisten adalah mencari tahu apa yang salah tanpa mengubah perkiraan cerita asli.