Cara menghitung nilai dalam Burn Down Chart di Scrum

Setelah publikasi di antara teman-teman artikel pertama tentang Burn Down Chart, di komentar pertanyaan kedua yang diajukan: "Tidak jelas bagaimana semua nilai ini dihitung". Oleh karena itu, dalam artikel ini saya akan mencoba menjelaskan bagaimana kami menghitung nilai harian pada Burn Down Chart. Seperti biasa, saya akan senang menerima semua komentar rekan-rekan jika tiba-tiba ada yang saya sampaikan kurang tepat, tetapi tetap ingin percaya bahwa topik ini cukup jelas bagi saya.

Mari kita ingat lagi bagaimana tampilan diagram ini.

Dalam contoh ini dipertimbangkan sprint 10 hari. Di dalamnya kita melihat bahwa telah berlalu 2 hari (karena hanya 2 segmen pertama yang diwarnai hijau oleh grafik).

Kita juga melihat total volume sprint - ini adalah garis putus-putus yang menunjukkan bahwa total volume sprint pada Senin pukul 10:00, Selasa pukul 10:00 dan Rabu pukul 10-00 tidak berubah dan sama dengan 17 SP (Story Points).

Menurut metodologi Scrum, total volume pekerjaan di dalam sprint tidak berubah selama sprint, oleh karena itu garis ini sering dibuat langsung untuk seluruh sprint (semua 10 hari). Garis ini juga membantu memperkirakan berapa banyak yang tersisa untuk dikerjakan lebih jelas daripada jika garis tersebut berakhir pada hari ketiga seperti pada varian saat ini.

Pembakaran nyata (grafik hijau) menunjukkan pekerjaan yang sebenarnya tersisa. Yaitu. saat ini tim telah menyelesaikan 1 Story Point dari 17 yang perlu diselesaikan untuk berhasil menyelesaikan sprint. Yang dianggap selesai paling sering adalah tugas dengan status "Done" (apa itu Done untuk setiap tim, tim menentukan sendiri. Bahkan ada artefak khusus yang disebut DOD - Definition Of Done - yang dimiliki setiap tim dan di dalamnya dijelaskan dengan sangat tepat apa artinya tugas selesai dan dapat dipindahkan ke status "Done". Paling sering ini adalah "Di-deploy ke prod", tetapi bisa ada nuansa. Secara umum, berdasarkan grafik saat ini kita memahami bahwa DOD hanya terpenuhi pada satu cerita yang dinilai tim sebesar 1 SP.

Pembakaran ideal menunjukkan pada titik mana grafik pembakaran nyata seharusnya berada jika pekerjaan benar-benar merata. Yaitu. saat ini seharusnya sudah diselesaikan 3 SP jika pekerjaan benar-benar merata.

Saya menduga mungkin menarik untuk memahami apa itu Story Point. Pada dasarnya, 1 SP pada satu tim dan 1 SP pada tim lain dapat menyembunyikan volume pekerjaan yang berbeda. Pada kami, misalnya, ada tim dengan jumlah orang yang sama, tetapi satu kapasitas per sprint 17 SP, sedangkan yang lain 35SP. Dan itu normal. Masalahnya adalah tim sendiri memilih tugas acuan untuk dirinya sendiri yang menjadi dasar penilaian semua tugas pada grooming (nama lama - ini adalah pertemuan mingguan di mana PO membawa User Stories untuk dinilai, dan tim menilainya melalui planning poker) (Di SAFe ini adalah PBR - Product Backlog Refinement).

Dengan demikian, kita dapat memiliki User Story acuan "Saya, sebagai pengemudi mobil, ingin setelah mengisi bahan bakar mobil, dapat jika perlu mendapatkan struk yang dicetak di atas kertas". Sepakati bahwa itu untuk tim kami 8SP. Dan, ketika PO menceritakan User Story baru yang harus kami nilai, kami menilainya relatif terhadap tugas acuan. Dengan demikian, yang baru bisa dinilai tim sebesar 5 SP, misalnya, dan seterusnya semua cerita backlog mendapatkan penilaiannya.

Kapasitas tim dihitung berdasarkan statistik. Pada 1-2 sprint pertama diukur jumlah SP yang diselesaikan tim dan dihitung nilai rata-ratanya, nilai inilah yang menjadi dasar perencanaan (ketika PO memilih tugas ke dalam sprint dari backlog untuk kapasitas tertentu).

Saya harap saya telah menjelaskan dengan cukup jelas bagaimana nilai-nilai pada Burn Down Chart diperoleh.