Praktik penggunaan Burn Down Charts dalam konteks SAFe dan Scrum

Dalam artikel ini saya berencana menceritakan bagaimana dalam praktik kami menggunakan diagram pembakaran (Burn Down Chart) dalam proses kerja dengan metodologi SAFe

Saya mulai saja dari hal yang paling menarik. Yaitu bahwa penggunaan diagram ini dalam SAFe tidak seharusnya memiliki kekhususan apa pun dibandingkan penggunaan diagram ini dalam SCRUM. Atau haruskah?

SAFe kami berbeda karena adanya peran seperti RTE, berbeda dengan SCRUM yang tidak memilikinya. Burn Down Chart adalah alat pelacak volume pekerjaan dalam sprint dan terutama diperlukan bagi tim SCRUM, bukan bagi siapa pun dari luar, bukan begitu?

Jadi, saya tetap akan beralih ke bagaimana kami menggunakan Burn Down Chart, terlepas dari apa pun, dan tetap berada di dalam framework SAFe.

Saya berada dalam peran Scrum Master dan berusaha menampilkan diagram ini setiap hari untuk seluruh Dev Team. Sarana yang saya gunakan adalah obrolan tim, menyebut seluruh tim melalui "@", tangkapan layar keadaan diagram saat ini. Menyebut seluruh tim adalah alat yang cukup halus dan penting untuk menggunakannya sesedikit mungkin (bukankah kita, para Scrum Master, harus membantu tim bekerja dengan nyaman dan dengan gangguan seminimal mungkin?)

Hasilnya, tim setiap hari melihat keadaan sprint saat ini dan mampu melacak peristiwa berikut

• Munculnya pekerjaan yang tidak direncanakan
• Tugas yang lama tertahan dalam status belum selesai
• Penempatan risiko yang berlebihan
• Pemahaman — apakah pekerjaan berjalan pada laju yang tepat

Selanjutnya saya akan berusaha menguraikan masing-masing peristiwa ini dan memberikan contoh dari praktik saya.

Munculnya pekerjaan yang tidak direncanakan

Pada diagram ini sangat terlihat bagaimana pekerjaan baru muncul (pada Selasa kedua sprint dua minggu).

Kasus dari praktik: "Pengembang, sebagai anggota tim scrum yang menganut prinsip agile, berinteraksi dengan baik dengan Product secara langsung. Product mengatakan kepadanya bahwa ini perlu dikerjakan dengan cepat, kamu sendiri paham, ini cepat dan risikonya minimal.

Pengembangnya hebat, dia tahu segalanya tentang agile dan tentang pentingnya memberikan nilai bisnis, dia pergi dan melempar ke papan sebuah cerita dari backlog, yang telah diperkirakan oleh tim sebesar 6 sp.

Bagian tim lainnya (selain pengembang dan Product) menyadari hal ini pada pembaruan diagram pagi hari. Pada standup tim mengambil keputusan bagaimana menangani situasi ini. Kemungkinan besar, cerita itu dikeluarkan dari sprint, tim memberi pemahaman kepada Product dan Pengembang bahwa tidak boleh melakukan hal seperti itu, product dapat memasukkan cerita ini ke sprint berikutnya jika perlu.

Tentu saja, idealnya tim harus menyadari munculnya pekerjaan baru pada standup tanpa diagram. Namun diagram adalah indikator yang baik yang meminimalkan risiko tidak menyadari perubahan penting bagi seluruh tim ini.

Di sini penting untuk dipahami bahwa skenario bisa berjalan berbeda tergantung pada tingkat kematangan tim. Pada tim yang hebat, Pemilik produk kecil kemungkinannya melakukan hal itu, dan jika pun melakukannya, dia akan berargumen bukan dengan "ini bisa dikerjakan dengan cepat", melainkan dengan "saya memperkirakan ada 55% kemungkinan bahwa jika ini dikerjakan sekarang, maka dapat meningkatkan keuntungan kita sebesar 20% pada bulan berikutnya" atau dengan metrik terukur lainnya.

Tugas yang lama tertahan dalam status belum selesai

Di sini kita melihat bahwa pekerjaan tidak selesai bahkan sebagian untuk waktu yang sangat lama. Ini dapat mengindikasikan berbagai masalah, saya akan menyebutkan beberapa di antaranya

• Dekomposisi tugas yang buruk

  Sangat sering tim pemula berbicara tentang ketidakmungkinan dekomposisi. Semuanya terbakar pada hari terakhir, pekerjaan tidak dapat diparalelkan, dll. Tentu saja, Scrum Master perlu menangani hal ini dan menjelaskan nilai dekomposisi kepada tim.

• DOD yang dirumuskan tidak optimal

  DOD (Definition of Done) - deskripsi kriteria kesiapan User Story dalam sprint. Terkadang kriteria tersebut tidak ada sama sekali atau dijelaskan sangat abstrak. Ini bisa menjadi masalah, yang tentu saja harus dibantu diselesaikan oleh Scrum Master

Penumpukan risiko yang berlebihan

Dalam kasus ini kita melihat situasi di mana tim menumpuk risiko secara berlebihan.

Mungkin ada cerita yang dinilai terlalu tinggi. Mungkin ini masalah yang lebih sistemik dan perlu menambah volume pekerjaan saat perencanaan sprint. Dalam kasus apa pun, situasi ini tidak tepat. Karena bisnis merencanakan bahwa yang akan diimplementasikan adalah tugas-tugas sprint dan tepat pada akhir sprint. Bergantung pada bagaimana dependensi direncanakan, di sini kemungkinan besar perlu mengadakan pertemuan untuk menyesuaikan ekspektasi.

Dalam pengalaman saya, hal ini terjadi ketika ditemukan solusi yang lebih cepat daripada yang dibahas saat estimasi. Kami membahas bersama seluruh tim cerita mana yang bisa diselesaikan hingga akhir sprint dan pada retrospektif kami sepakat bahwa kami akan berusaha melihat kode saat grooming. Ternyata cukup dengan melihat kode untuk memahami bahwa solusinya jauh lebih sederhana.

Pemahaman - apakah pekerjaan berjalan pada kecepatan yang tepat

Di sini saya ingin menarik perhatian pada cara grafis yang kurang berhasil untuk menampilkan Burn Down Chart

Di bagian atas gambar diberikan contoh implementasi grafis yang kurang berhasil karena dua alasan yang akan saya jelaskan di bawah.

• Penambahan SP baru ke dalam sprint tidak terlihat

  Di sini, pada diagram atas, hampir tidak terlihat bahwa ada pekerjaan tak terencana yang ditambahkan. Pada diagram bawah ini lebih jelas.

• Sisa pekerjaan relatif ditampilkan secara tidak tepat

  Menurut diagram atas, masih ada 3 hari kerja tersisa. Faktanya tinggal 2 hari, pada hari libur, mungkin seseorang berencana untuk beristirahat.

Tentu saja, bagi sebagian orang hal-hal kecil seperti ini tampak tidak signifikan. Tetapi perlu dipahami bahwa setiap anggota tim hanya akan melirik sekilas diagram ini dan diagram tersebut harus menyampaikan informasi yang maksimal dan bermanfaat.