3 laporan burndown tangkas dan cara menggunakannya

Praktik tangkas, bagi yang belum tahu dan kurang informasi, terkadang dapat muncul sebagai pengembangan perangkat lunak ad hoc dan metodologi manajemen proyek. Kebenarannya jauh berbeda.

Salah satu dari 12 prinsip perangkat lunak tangkas menyatakan, "Arsitektur, persyaratan, dan desain terbaik muncul dari tim yang mengatur dirinya sendiri," tetapi sebagian besar organisasi yang menerapkan praktik tangkas, termasuk scrum dan Kanban, menerapkan beberapa ritual dan kekerasan proses yang signifikan. Misalnya, banyak organisasi menerapkan praktik perencanaan yang gesit termasuk estimasi poin cerita, standar arsitektur, dan disiplin manajemen rilis untuk meningkatkan dampak bisnis, kualitas, dan keandalan rilis aplikasi.

Sebagian besar tim memilih untuk menggunakan alat tangkas seperti Jira Software atau Azure DevOps untuk mengelola backlog, sprint, dan kolaborasi antara tim tangkas. Tujuan utama alat ini adalah untuk mengelola persyaratan, status sprint, alur kerja, dan kolaborasi secara terpusat di seluruh anggota tim yang gesit dan beberapa tim tangkas. Namun, semakin ketat organisasi menggunakan alat ini, semakin banyak alat ini dapat membantu para pemimpin dan tim mengidentifikasi masalah, melaporkan kepada pemangku kepentingan tentang status, dan meningkatkan pelaksanaannya.

Salah satu laporan out-of-the-box yang paling umum adalah laporan burndown. Karena praktik agile memungkinkan pemilik produk memprioritaskan kembali backlog berdasarkan umpan balik pelanggan, laporan tradisional seperti diagram Gantt gagal menangkap sifat fluid dari eksekusi agile. Yang mendasar dari grafik burndown adalah bahwa itu memperhitungkan pekerjaan yang sudah selesai, pekerjaan baru ditambahkan ke ruang lingkup, dan perubahan ruang lingkup lainnya. Grafik burndown dapat memberikan gambaran singkat tentang bagaimana tim bergerak menuju tujuan mereka.

Membaca grafik burndown sprint dasar

Bagan burndown biasanya memiliki waktu melintasi sumbu x dan perkiraan pada sumbu y. Banyak tim memperkirakan poin cerita, tetapi banyak alat gesit yang dapat memetakan burndown berdasarkan jumlah cerita atau perkiraan dalam hitungan jam. Untuk artikel ini, saya akan mengasumsikan poin cerita digunakan.

Laporan sprint burndown memplot jumlah poin cerita yang berada dalam cakupan untuk interval waktu. Saat tim menyelesaikan cerita, bagan menunjukkan bagaimana mereka "membakar" daftar cerita dan jenis pekerjaan lainnya (masalah di Jira, jenis item pekerjaan di Azure DevOps) hingga pekerjaan selesai atau sprint berakhir. Ketika tim menyelesaikan pekerjaan yang berkomitmen pada sprint, garis yang diplot memotong sumbu x, menunjukkan semuanya sudah selesai.

Sprint burndown adalah yang paling mudah untuk dikonsep. Pada hari pertama sprint, tim berkomitmen pada beberapa cerita dan jumlah total poin cerita. Jika Anda meninjau grafik burndown pada hari itu, Anda akan melihat satu titik pada sumbu y yang mewakili jumlah poin yang berkomitmen tim pada hari nol sprint.

Saat story ditandai selesai, sprint burndown menunjukkan jumlah poin yang tersisa untuk diselesaikan.

Bagaimana sprint burndown digunakan dalam praktiknya? Burndown yang sehat menunjukkan kurva eksponensial linier dan idealnya ke nol. Jika kurva memiliki kemiringan datar di bagian awal sprint, ini mungkin menunjukkan blok atau banyak pekerjaan yang sedang berlangsung dan bahwa sprint mungkin berisiko. Burndown yang datar atau landai bisa sangat bermasalah jika banyak pengujian dilakukan pada story-story yang lengkap dan jika pekerjaan pengujian tidak dapat dimulai hingga beberapa hari terakhir sprint.  

Sprint burndown yang menurun dengan cepat umumnya merupakan hal yang baik, tetapi ini mungkin menunjukkan bahwa tim kurang berkomitmen atau hanya memilih untuk mengambil cerita yang lebih kecil dalam sprint.

Burndown epik melacak kemajuan terhadap bisnis dan pengemudi teknis

Sprint burndown sangat berguna untuk melacak eksekusi jangka pendek dan membantu tim berhasil memenuhi komitmen sprint. Untuk melacak kemajuan dengan lebih baik terhadap tujuan jangka panjang, burndown epik dan rilis memberikan visibilitas yang dibutuhkan.

Pembakaran epik bekerja paling baik saat tim menentukan beberapa upaya jangka panjang, seperti menerapkan kapabilitas pengguna akhir utama, strategi utang teknis, peningkatan kinerja, atau evolusi proses. Untuk memanfaatkan burndown epik, backlog harus memiliki:

  • Antara lima dan 15 epos yang akan berlangsung setidaknya beberapa bulan dan membutuhkan enam atau lebih sprint untuk diselesaikan.
  • Fitur, cerita, dan rintisan cerita yang muncul di bawah epik dan mewakili rencana tingkat tinggi untuk dieksekusi pada epik.
  • Estimasi tingkat tinggi, idealnya dalam poin cerita untuk setiap cerita atau rintisan cerita yang muncul di bawah epos.

Setelah ini diterapkan, burndown epik memetakan perubahan pada rencana ini. Sumbu x mewakili sprint, dan sumbu y mewakili perkiraan total cerita dan stub cerita yang ditetapkan untuk epik. Dalam grafik burndown epik Jira Software, Anda melihat grafik batang dengan satu warna mewakili cerita yang diselesaikan dalam sprint dan yang kedua menunjukkan poin cerita yang ditambahkan. Poin cerita meningkat saat cerita baru atau potongan cerita ditambahkan ke epik atau saat perkiraan berubah.

Ada beberapa cara untuk menggunakan grafik burndown epik:

  • Ini menggambarkan kecepatan penyelesaian fitur dan cerita terhadap rencana. Ketika rencana akurat dan kecepatan tim konsisten, itu dapat memberikan indikator kapan pekerjaan epik selesai.
  • Sebagian besar rencana tangkas tidak lengkap, dan tim menambah, mengubah, dan menghapus cerita berdasarkan umpan balik pengguna akhir, penemuan kerumitan teknis, dan untuk mengatasi hutang teknis yang muncul selama perjalanan. Burndown epik kemudian menunjukkan seberapa jauh rencana epik didasarkan pada seberapa banyak backlog berkembang versus diselesaikan sprint demi sprint.
  • Burndown yang epik juga membantu upaya benchmark di beberapa sprint dan mengukur seberapa banyak perencanaan dan pekerjaan pengiriman yang dilakukan dalam satu epik versus yang lain.

Burndown rilis memberi tahu tim apakah rilis akan mencapai tanggal dan cakupan

Tim tingkat lanjut yang sepenuhnya mengotomatiskan pipeline pengiriman mereka dengan integrasi berkelanjutan, pengujian berkelanjutan, dan pengiriman berkelanjutan mungkin tidak memerlukan burndown rilis. Tim yang sering menerapkan harus melacak fitur dan cerita apa yang terkait dengan rilis, tetapi burndown rilis tidak terlalu berguna karena sering melacak kemajuan dengan sprint.

Untuk tim lain yang mengikuti praktik manajemen rilis dan melakukan standarisasi pada rilis multisprint, burndown rilis mungkin merupakan alat paling penting bagi pemilik produk dan tim.

Burndown rilis mirip dengan burndown epik kecuali fitur pelacakan, cerita, dan stub cerita yang ditetapkan ke sebuah epik, burndown rilis menunjukkan apa yang ditetapkan ke sebuah rilis. Sumbu dan palang kemudian identik dengan burndown epik.

Tim yang menggunakan burndown rilis dapat melacak cakupan dan garis waktu rilis. Tim yang berada di jalur akan melihat kemiringan burndown ke sumbu x dengan kemiringan yang sesuai dengan kecepatan tim. Rilis yang mungkin membelok keluar jalur memiliki kemiringan yang lebih kecil atau menggambarkan lebih banyak poin cerita yang ditambahkan (ketika lebih banyak cakupan ditambahkan ke rilis) daripada yang sedang diselesaikan.

Jira Software membantu Anda dengan proyeksi ini. Dengan asumsi tim telah mengerjakan proyek setidaknya selama tiga sprint, Jira Software akan menghitung kecepatan tim rata-rata dan memprediksi sprint akhir untuk rilis berdasarkan kecepatan ini.

Sprint, epik, dan burndown rilis memberi tim beberapa alat yang mudah digunakan untuk menyelaraskan tujuan. Ketika tim memiliki pemahaman yang sama tentang ruang lingkup, menyepakati prioritas, merencanakan beberapa sprint ke depan, dan menandai cerita di backlog mereka dengan tepat, burndown menceritakan kisah apakah perencanaan dan pelaksanaan selaras dengan tujuan. Jika tidak, mereka adalah alat berbasis data yang dapat memicu diskusi tentang penyesuaian apa yang mungkin diperlukan.