Dalam 10 bulan terakhir ini saya bergabung di satu tim pengembang (development team) yang menggunakan Scrum. Selama itu juga saya mengumpulkan dan mengolah data, dikemudian hari data ini akan sangat berguna.
Seperti yang kita ketahui, Scrum didasari oleh empirisme. Singkatnya data-data ini akan dipakai untuk membantu tim dan organisasi — pada saatnya nanti, membuat keputusan. Ya, yang saya lakukan adalah saya membuat Evidence Based Management. Namun dalam tulisan hanya beberapa data yang bisa saya bagikan.
Evidence-Based Management is a framework organization can use to help them measure, manage, and increase the value they derive from their product delivery. EBM focuses on improving outcomes, reducing risks, and optimizing investments. — Scrum.org
Di EBM ini ada beberapa hal yang saya tambahkan sendiri berdasarkan temuan saya dengan tim. Oh ya, saya menggunakan template milik Joshua Partogi yang dijelasksan di video ini. Buat saya ini sangat sederhana dan mudah dipelajari karena menggunakan Google Spreadsheet. Hail Spreadsheet!
Velocity
Yes, velocity! Buat sebagian orang angka ini sangat penting. Konon, angka ini yang menggambarkan bagus tidaknya tim Scrum.
“Kalau mau liat tim yang pake Scrum bagus atau enggak, liat aja velocity-nya”
Gambar diatas adalah velocity kami, nilai rata-ratanya adalah 27 dalam 21 sprint. Angka 27 ini biasanya kami jadikan patokan dalam menentukan besarnya total backlog yang akan kami ‘angkut’ untuk sprint selanjutnya. Hal lain yang kami lakukan juga biasanya hanya melihat angka rata-rata 4 sprint sebelumnya. Kenapa naik turun? Tentu saja karena kami manusia, bukan mesin yang bisa di-setting jika rusak atau bermasalah.
Perhatikan Sprint 7, 8, dan 9. Ini adalah salah satu performa terbaik kami, namun di Sprint 10 kami jatuh, angkanya turun sangat signifikan. Hal yang sama terjadi di sprint 10–13, disini kami masih ‘jatuh’ namun secara mengejutkan kami bisa kembali bangkit di Sprint 14 walaupun sprint berikutnya kami jatuh kembali.
Jika ada seorang manager atau pimpinan perusahaan, menurut saya sangat tidak bijak menilai kemampuan tim hanya dari angka-angka tersebut. Ada banyak sekali faktor — internal dan eksternal, yang mengakibatkan performa tim naik turun. Langkah yang bisa anda lakukan adalah melihat data lainnya, data yang bisa saya berikan adalah melihat hasil retrospective setiap sprint.
Layaknya seorang dokter menganalisa penyakit, dibutuhkan lebih dari satu data dan juga lebih dari satu variabel sebelum memutuskan jenis penyakit apa yang diderita pasien
Sayangnya, saya tidak bisa membeberkan rahasia dapur disini, namun kami jelas punya data apa saja yang menyebabkan kami jatuh, dan juga apa yang menyebabkan kami bangkit.
Jika kita hanya melihat kemampuan tim dari angka velocity saja, mari berharap angka-angka ini tidak “dimainkan”.
Credit: Facebook Agile Memes
Output
Ini perbadingan antara velocity dan output backlog dalam 20 Sprint.
Output atau banyaknya backlog yang bisa kami hantarkan setiap sprint pun sama, bisa saya bilang berbanding lurus dengan velocity, ya jelas saja.
Lagipula tidak ada kaitannya antara output dan performa tim Scrum, betul kan? Tim Scrum yang baik mengukur outcome daripada output, saya yakin kita semua yang menggunakan Scrum dengan pola pikir Agile berfikir demikian. Betul kan?
Gagal estimasi
Jujur saja, kami payah dalam melakukan estimasi, bahkan kami sangat tidak berbakat melakukan estimasi. Walaupun angka estimasi sering kami revisi ditengah sprint, namun tetap tidak bisa menutupi kegagalan kami melakukan estimasi.
Data diatas adalah perbandingan antara nilai estimasi dan durasi (dalam hari) kami menyelesaikan backlog.
Bisa diperhatikan betapa kacaunya estimasi kami, cycle time backlog bernilai 2 bisa sama dengan backlog bernilai 5 bahkan 8. Sebagai contoh untuk nilai estimasi 1 yang notabenenya sangat kecil, pernah kami selesaikan dalam 8 hari dan itu terjadi dua kali! Kami tidak ingat apakah backlog tersebut tidak kami revisi atau memang kami memang malas melakukannya.
Saya sendiri sudah tidak terlalu melihat nilai velocity, toh itu kan hasil estimasi, perkiraan, bukan sesuatu yang bersifat kekal.
"Lebih baik meningkatkan skill ngoding daripada meningkatkan skill estimasi”
Intinya, tidak ada gunanya mengaitkan nilai estimasi dengan durasi pengerjaan. Apalagi mengasah kemampuan estimasi.
Tapi kan, estimasi tetap penting
Saya sepakat, estimasi tetap diperlukan namun rasanya velocity bukan hal yang tepat, setidaknya bagi saya saat ini.
Ngomong-ngomong, sampai disini kesimpulan saya adalah velocity kurang tepat dijadikan alat ukur kemampuan tim, lalu melihat betapa payahnya kami dalam mengestimasi backlog dan menjadikan velocity sebagai acuan bahan forecasting untuk Sprint Planning pun, saya ragu.
Saat ini saya sedang berusaha menerapkan salah satu praktik Kanban pada tim ini, yaitu Service Level Expectation (SLE)
An SLE forecasts how long it should take a given item to flow from start to finish within your workflow. The SLE itself has two parts: a period of elapsed days and a probability associated with that period. — Kanban Guide for Scrum Teams
Hal yang pertama saya analisis tentunya adalah development cycle time, adalah waktu yang dibutuhkan sebuah backlog dari hari pertama dikerjakan hingga Done.
Development Cycle Time
Hasilnya sebagai berikut:
“Kok ada yang merah, pak?”
Offside, pak. Timebox sprint kami adalah 2 minggu, artinya ideal waktu maksimal setiap backlog — ideal sesuai estimasi kami pada saat Sprint Planning, adalah 10 hari, namun kenyataannya ada beberapa backlog yang offiside. Bahkan ada yang sampe sebulan baru Done, mohon jangan tanya kenapa.
Dan, nilai SLE kami sebagai berikut:
Service Level Expectation
Sesuai pengertian SLE diatas tadi, ada kaitan nilai probabilitas dan durasi (hari):
Ada kemungkinan sebesar 48% backlog akan selesai dalam 6 hari, atau
Ada kemungkinan sebesar 61% backlog akan selesai dalam 8 hari, atau
Ada kemungkinan sebesar 91% backlog akan selesai dalam 10 hari
“Kenapa gak dihitung sampai 100%, pak?”
Karena probability, kemungkinan. Kalau 100% itu kepastian, certainty.
Kemudian, saya pun mencoba menghitung ̶t̶h̶r̶o̶u̶g̶h̶p̶u̶t̶ output, hasilnya sebagai berikut:
Rata-rata perminggunya adalah 4.3 artinya dalam 1 minggu kami sanggup menghantarkan sekitar 4 backlog. Jika dalam 2 minggu atau satu sprint kami sanggup menghantarkan sekitar 8 backlog. Tentunya dengan catatan tidak ada kendala yang signifikan selama sprint berjalan, seperti tiba-tiba ada anggota yang sakit atau internet yang lagi galau.
Dari dua. data SLE dan t̶h̶r̶o̶u̶g̶h̶p̶u̶t̶ output diatas, bisa disimpulkan:
Ada 91% kemungkinan 8 backlogs akan selesai dalam 10 hari
Saya ambil contoh angka paling besar 91%, karena nilai yang besar "sangat menjual" untuk tim bisnis, apalagi klien :D
Apakah ini lebih cocok daripada velocity?
Jujur saja, pada tahap ini saya belum bisa mengenalkan praktik ini kepada tim sekarang. Salah satu hal yang menghambat saya mengenalkan SLE ini adalah karena kami masih “harus” menggunakan story point.
Ya, hasil data-data diatas kurang akurat menggambarkan SLE yang sebenarnya. Untuk bisa mendapatkan angka yang lebih akurat, tim Scrum yang ingin menggunakan SLE haruslah merubah cara estimasinya. Setiap backlog memiliki nilai yang sama atau setidaknya tidak jauh berbeda, misalnya 1 dan 2 saja.
Karena jika semua product backlog yang siap dikerjakan memiliki nilai yang sama, maka akan menjawab pertanyaan:
“4 backlog yang sebesar apa (backlog yang memiliki nilai berapa) yang sanggup dihantarkan dalam 10 hari?”.
Saat ini jawaban saya adalah tidak tahu.
Untuk bisa membuat backlog memiliki nilai yang sama, caranya tentu saja mengiris (slicing) kembali backlog-backlog yang ada sehingga Product Backlog yang siap diwujudkan tersebut senilai.
Slicing product backlogs into smaller items is not an easy job.
Ekpektasi menggunakan SLE
Hal yang paling membedakan velocity dan SLE adalah keakuratan. Namun sekali lagi perlu dicatat, tidak ada nilai kepastian.
Harapannya dengan menggunakan SLE, tim tidak perlu lagi melakukan planning poker dan semacamnya, setiap backlog akan selalu diiris bernilai 1 atau 2.
Kanban sendiri menyebutnya dengan istilah throghput. Throughput memiliki nilai (value) yang dianggap sepadan.
In Kanban, throughput is the amount of work delivered over a specified period. In short, throughput is a metric for how much work, or progress, you deliver by the end of a project. Throughput doesn’t count any unfinished work.
Nilai SLE juga menjadi warning tim harus berbuat sesuatu. Sebagai contoh SLE tim A adalah, “ada 80% kemungkinan backlog akan selesai dalam 6 hari”. Hal ini juga berarti, jika ada backlog yang masih diam di In Progress selama 7 hari, artinya hanya ada 20% atau kurang kemungkinan backlog tersebut bisa dihantarkan pada sprint tersebut.
Yang kedua, akan lebih mudah bagi Product Owner dalam menyusun Product Roadmap. Product Owner dengan sendirinya bisa menghitung dan memproyeksikan dengan sisa backlog yang ada akan membutuhkan waktu berapa lama dan seberapa besar probabilitasnya bisa diwujudkan menjadi increment.
Lanjutan tulisan mengenai EBM
PS: Tulisan ini berdasarkan perspektif saya, feedback is welcome. Semoga membantu.