Estimasi Menggunakan Story Point pada User Story

Apakah kamu pernah ditanya oleh klien atau mungkin manajer kamu, “berapa lama ya kira-kira untuk menyelesaikan fitur ini?” Di kondisi seperti ini, kamu mau ga mau harus melakukan yang namanya estimasi, melihat ke depan lalu memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikan fitur tersebut. Saat mengestimasi suatu fitur, kita berusaha untuk membuat estimasi yang seakurat mungkin. Sayangnya, ini bukanlah hal yang mudah. Selalu ada kemungkinan bahwa estimasi yang kita buat tidak akurat. Meskipun tidak akurat, kita berharap nilai kenyataannya tidak berbeda jauh dari nilai estimasi kita.

Saat kita memilih untuk menuliskan requirements dalam user story, kita direkomendasikan menuliskan estimasinya menggunakan story point. Yup, story point dibuat untuk mendukung estimasi menggunakan user story dalam pendekatan Agile. Ketika kita membuat suatu user story, kita cenderung menuliskan estimasi dalam waktu, bisa berupa hari atau jam. Misalnya kita mengatakan untuk mengimplementasikan suatu user story dibutuhkan waktu 2 hari. Berbeda dengan estimasi dalam waktu, story point pada user story tidak menggunakan satuan waktu dan hanya menuliskan nilai tanpa satuan. Story point mungkin saja berkorelasi dengan waktu, tapi itu tidak selalu terjadi. Menarik kan konsep dari story point? Mari kita bahas lebih dalam. 😀

Story point menggambarkan usaha (effort) yang dibutuhkan untuk menyelesaikan implementasi suatu user story. Nilai usaha ini akan dipengaruhi oleh kompleksitas dan resiko saat implementasi user story tersebut. Makin sulit menyelesaikan user story tersebut dan makin tinggi resiko yang dihadapi saat implementasinya, nilai story point-nya akan makin lebih besar dari yang seharusnya. Sebagai contoh, suatu user story dituliskan oleh product owner sebagai berikut.

ID: 01
Sebagai penjual, saya ingin menambahkan barang baru sehingga saya bisa jualan barang baru tersebut

Untuk mengetahui maksud dari user story di atas lebih jauh, kita perlu menanyakan beberapa pertanyaan ke product owner seperti info apa saja yang diperlukan untuk menambahkan barang baru ke sistem, mana info yang wajib diisi oleh penjual dan mana yang opsional. Product owner selanjutnya menjelaskan info apa saja yang diperlukan untuk menambahkan barang baru. Namun sayangnya, itu semua masih asumsi product owner dan dia mengatakan bahwa info tersebut mungkin saja berubah. Product owner ingin bertemu dengan beberapa representasi calon penjual terlebih dahulu untuk mendapatkan info penambahan barang baru yang sesuai kebutuhan penjual. Dalam ketidakpastian ini, memilih user story tersebut untuk dikerjakan saat ini tentu saja memiliki resiko lebih. Dalam hal ini, kita bisa menaikkan nilai story point dari yang seharusnya kita pikir lalu merevisinya di kemudian hari saat sudah ada info yang lebih akurat dari product owner.

Hal yang menarik dari story point adalah story point tidak menggunakan satuan waktu dalam estimasi seperti hari atau jam. Well, that is surprising for me for the first time! Story point malahan menggunakan nilai tanpa satuan. Nilai tersebut menggambarkan banyaknya usaha yang relatif terhadap user story lainnya yang kita miliki. Seandainya saya memilih suatu user story yang saya anggap mudah dan sederhana, saya bisa menjadikan user story tersebut sebagai user story dasar untuk mengestimasi user story lain. Saya bisa menilai user story lain lebih besar usahanya dua kali, tiga kali, atau lima kali lipat berdasarkan user story dasar yang saya pilih.

Ada dua buah pendekatan dalam menuliskan story point yang populer digunakan, yaitu menggunakan angka dan menggunakan ukuran baju.

Story Point dalam Angka
Story point bisa direpresentasikan dengan angka untuk menggambarkan usaha yang dibutuhkan untuk mengimplementasikan suatu user story. Pada dasarnya, kita bisa menuliskan sembarang angka dalam bilangan bulat positif sebagai estimasi pada suatu user story, misalnya 2, atau 8, atau mungkin 100, asalkan tetap memenuhi sifat relatif-nya story point. Sebagai contoh, kita memiliki suatu user story yang dianggap mudah. Kemudian kita memberikan nilai estimasi 100 untuk user story tersebut dan menjadikannya sebagai user story dasar. Seandainya kita memiliki user story lain yang kita pikir banyaknya usaha dua kali lipat dari user story dasar, user story lain tersebut kita beri nilai 200.

Untuk membuat estimasi lebih mudah dan sederhana, ada dua buah cara yang digunakan dalam menuliskan angka sebagai estimasi. Yang pertama adalah menggunakan angka yang bernilai relatif kecil daripada angka yang relatif besar. Dan yang kedua adalah menggunakan bilangan Fibonacci daripada bilangan bulat positif.

Untuk suatu user story, developer lebih mudah membayangkan banyaknya usaha pada user story bernilai 3 terhadap user story dasar bernilai 2. Implementasi user story bernilai 3 membutuhkan usaha 50% lebih banyak dari user story dasar, atau 1.5 kali lipat dari user story dasar. Implementasi user story bernilai 8 membutuhkan usaha 4 kali lipat dari user story dasar. Jika user story dasar awalnya sudah bernilai 50, user story yang usahanya 1.5 kali lipat akan bernilai 75 dan user story yang usahanya 4 kali lipat akan bernilai 200. Meskipun memungkinkan menggunakan angka yang besar, menggunakan angka yang kecil tentu saja lebih praktis.

Penggunaan bilangan Fibonacci akan membuat estimasi jadi lebih sederhana. Bilangan Fibonacci adalah bilangan yang diperoleh dari urutan angka yang dimulai dari angka 0 dan 1, kemudian angka-angka berikutnya diperoleh dengan menjumlahkan dua angka sebelumnya.

Bilangan Fibonacci:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …

Jika melihat arti di balik angka pada suatu user story, makin tinggi nilai story point-nya, makin tidak penting keakuratannya. Misalnya ketika dua developer dalam satu tim yang sama mencoba mengestimasi suatu user story. Seorang developer memberi angka 3, yang satunya memberi angka 2. Melihat perbedaan angka ini, kedua developer tersebut berdiskusi mengenai apa yang mereka asumsikan dan pahami mengenai user story tersebut hingga mereka mendapatkan kesepakatan nilai estimasi yang sama untuk user story tersebut. Perbedaan nilai ini cukup signifikan karena user story dengan angka 3 berarti membutuhkan usaha 50% lebih banyak dari user story dengan angka 2. Kemudian kedua developer tersebut berlanjut ke user story yang lain. Seorang developer memberi angka 20, yang satunya memberi angka 23. Di titik ini, mereka bisa langsung sepakat di angka 21 dengan mengambil angka terdekat dari nilai estimasi mereka pada bilangan Fibonacci. User story dengan angka 23 berarti membutuhkan usaha 9.5% lebih banyak dari user story yang dipilih dengan angka 21. User story dengan angka 20 berarti membutuhkan usaha 4.7% lebih sedikit dari user story yang dipilih dengan angka 21. Perbedaan nilai estimasi ini dianggap tidak signifikan. Jika ternyata implementasi user story tersebut membutuhkan usaha lebih banyak dari yang diperkirakan, kedua developer tersebut berharap usaha ekstra yang dibutuhkan relatif tidak banyak. Jika ternyata lebih sedikit, mereka bisa menggunakan “usaha yang tersisa” untuk mengimplementasikan user story yang lain atau sekedar menutup “usaha ekstra” di story yang lain.

Story Point dalam Ukuran Baju
Ini sebenarnya adalah representasi angka yang disederhanakan menjadi beberapa kategori. Estimasi dituliskan dalam ukuran baju dalam menggambarkan usaha implementasi dari suatu user story. Sebagai contoh, kita bisa mendefinisikan 6 jenis ukuran, yaitu:

XS (Extra Small)
S (Small)
M (Medium)
L (Large)
XL (Extra Large)
XXL (Extra Extra-Large)

User story yang dianggap kecil usaha implementasinya dan umumnya sederhana bisa diberi nilai XS atau S. User story yang dianggap besar dan kompleks bisa diberi nilai L. User story yang kira-kira tidak besar tapi juga tidak kecil, dan tidak kompleks tapi juga tidak sederhana, bisa kita beri nilai M. Jika kita pikir ketidakpastian dalam implementasi suatu user story makin tinggi yang berarti usaha implementasinya makin besar, kita bisa mempertimbangkannya untuk memberikan nilai XL atau XXL. Sederhana kan? 😀

—

Dalam kaitannya dengan waktu, story point efektif digunakan dalam pengembangan yang iteratif. Untuk suatu iterasi (rentang waktu tertentu), kita bisa memilih seberapa banyak user story yang ingin kita ambil untuk dikerjakan dalam rentang waktu tersebut. Dengan kata lain, kita memilih jumlah story point yang mampu kita ambil dalam satu iterasi. Di penghujung iterasi, kita bisa menghitung jumlah story point yang dikumpulkan dari user story yang berhasil diselesaikan dan itu akan menjadi masukan untuk iterasi berikutnya.

Story point adalah cara baru dalam estimasi. Menggunakan story point dalam mengestimasi user story adalah hal yang direkomendasikan meskipun agak sulit saat pertama kali mencobanya. Story point memberikan pengalaman baru bagi kita dalam mengestimasi kerjaan pengembangan software. And it is worth to try.

Jika kamu punya pertanyaan mengenai story point ini, silakan langsung tanya saja di kolom komentar di bawah ini. 😀

Happy learning!

 

Referensi:

1. Cohn, Mike. User Stories Applied: For Agile Software Development. Boston: Pearson Education, 2004. Print.
2. Ambler, Scott W., and Matthew Holitza. Agile for Dummies, IBM Limited Edition. Hoboken: John Wiley & Sons, 2012.

Menulis Requirements dalam User Story

Saat awal mengembangkan software, kita pastinya menuliskan daftar kebutuhan yang ingin dihadirkan dalam software yang akan dibuat. Daftar kebutuhan ini bisa didapatkan dari klien, dari user yang akan menggunakan software, atau bisa juga dari riset pasar mengenai apa sih solusi yang pas untuk menjawab kebutuhan pengguna. Dari daftar kebutuhan tersebut, kita bisa mendetailkan lebih lanjut untuk mendapatkan gambaran mengenai fitur dan fungsi dari software yang akan dibuat. Dalam pengembangan software, deskripsi dari daftar kebutuhan ini disebut requirements.

Ada banyak cara untuk menuliskan requirements. Dalam pengembangan software menggunakan pendekatan Agile, user story adalah yang populer digunakan dalam menuliskan requirements karena kesederhanaannya. Kenapa sederhana? Karena kita tidak perlu menuliskan requirements begitu detail dan komprehensif dalam dokumen yang berlembar-lembar banyaknya dalam menggambarkan fitur dan fungsi dari software. User story memiliki format yang sederhana, mudah dimengerti oleh orang bisnis maupun orang teknis, dan menyenangkan. User story juga mudah dikelola secara efektif selama masa pengembangan software. Dan hal yang terpenting dari user story adalah user story mendorong kolaborasi orang-orang yang terlibat di pengembangan software, baik itu orang bisnis maupun orang teknis, untuk selalu berdiskusi melakukan percakapan mengenai fungsionalitas yang ingin dibuat.

Jadi apa itu user story?

User story adalah deskripsi singkat dan sederhana mengenai fitur atau fungsi dari software, dilihat dari sudut pandang pengguna. User story dituliskan dalam bahasa bisnis dari pengguna software. Deskripsi user story umumnya hanya satu atau dua kalimat. Dalam sehari-hari, user story bisa dituliskan di sticky notes lalu ditempelkan di suatu papan tulis atau dinding sehingga dapat dengan mudah dilihat dan didiskusikan oleh development team.

Ada tiga buah aspek yang menyusun user story, yaitu Card, Conversation, dan Confirmation. Saat menuliskan requirements dalam bentuk user story, kita perlu mengingat tiga aspek tersebut, tiga aspek penting yang tidak terpisahkan satu sama lain.

1. User Story sebagai Card
Sebagai Card, user story menggambarkan deskripsi tertulis mengenai fungsionalitas tertentu dari software. Deskripsinya singkat seolah-olah ditulis di sebuah kertas yang ukurannya relatif kecil, ya kira-kira sebesar kartu nama kita pada umumnya. Dengan tempat yang terbatas seperti itu, itu sudah lebih dari cukup untuk menuliskan requirement dalam bentuk user story.

Berikut ini contoh template dalam menuliskan user story.

Sebagai <jenis pengguna>, saya ingin <melakukan tindakan tertentu atau mendapatkan suatu fungsi tertentu> sehingga <mendapatkan manfaat atau nilai bisnis tertentu>

Untuk mendapatkan gambaran lebih jelas mengenai penggunaan user story, sekarang bayangkan kita sedang terlibat di suatu project untuk membangun sebuah Learning Management System yang menyediakan konten pembelajaran melalui kuliah online terbuka untuk publik. Berikut ini merupakan sedikit dari user story yang kita kumpulkan untuk sistem tersebut berdasarkan template di atas.

ID: 01
Sebagai peserta, saya ingin melihat daftar mata kuliah terbaru yang tersedia sehingga saya bisa mengetahui daftar mata kuliah apa saja yang ditawarkan

ID: 02
Sebagai peserta, saya ingin mencari mata kuliah dengan memasukkan judul atau topik tertentu sehingga saya bisa menemukan kuliah yang mungkin saya minati

ID: 03
Sebagai peserta, saya ingin mendaftarkan diri di suatu mata kuliah tertentu sehingga saya bisa mengikuti pembelajaran di mata kuliah tersebut

ID: 04
Sebagai pengajar, saya ingin mendapatkan daftar peserta kuliah di mata kuliah yang saya ajarkan sehingga saya bisa mengetahui berapa banyak orang yang berminat di topik perkuliahan saya

ID: 05
Sebagai pengajar, saya ingin meng-upload materi pembelajaran sehingga para peserta kuliah bisa belajar dari materi tersebut

Dari lima buah user story di atas, kita bisa menemukan dua jenis pengguna yang berinteraksi dengan sistem, yaitu peserta kuliah dan pengajar. Ketika kita mendalami dan mengumpulkan requirements lebih lanjut, kita bisa menemukan jenis pengguna yang lain dengan karakteristik berbeda yang akan menggunakan sistem yang akan dibuat ini. Setiap jenis pengguna memiliki tindakan-tindakan tertentu dalam mencapai tujuannya saat menggunakan sistem.

Sebagai tambahan, saya menambahkan nomor unik ID pada suatu user story seperti contoh di atas untuk memudahkan pengelolaan user story sekaligus membedakan satu user story dengan yang lainnya. Kita bisa menambahkan informasi lainnya yang umumnya dibutuhkan seperti estimasi ukuran pengerjaan user story dan kategori user story. Untuk estimasi ukuran pengerjaan user story, insya Allah akan dibuat di tulisan yang lain.

2. User Story sebagai Conversation
Jika melihat aspek Card pada user story, kita hanya akan menemukan deskripsi singkat yang bersifat umum mengenai fungsionalitas yang ingin dibuat. Kita tidak mendapatkan banyak detail mengenai fungsionalitas tersebut. Development team pun tidak dapat bekerja hanya dengan mengandalkan deskripsi singkat dari suatu user story.

Melalui aspek Conversation, user story berperan sebagai reminder untuk mengadakan diskusi melakukan percakapan lebih lanjut antara development team dengan klien. Banyak hal detail terkait suatu user story akan didapatkan setelah melakukan percakapan. Kolaborasi intensif antara development team dengan klien melalui percakapan ini dapat memperjelas requirements yang masih samar dan menangkap maksud yang masih tersembunyi.

Untuk lebih jelasnya, saya akan memilih user story dengan ID 02 sebagai contoh.

ID: 02
Sebagai peserta, saya ingin mencari mata kuliah dengan memasukkan judul atau topik tertentu sehingga saya bisa menemukan kuliah yang mungkin saya minati

Saat membaca user story tersebut, kemungkinan akan banyak pertanyaan yang terlintas di pikiran developer seperti:

• Apakah pengguna harus dalam keadaan login terlebih dahulu untuk melakukan pencarian mata kuliah?
• Bedanya judul dan topik itu apa ya?
• Apakah mata kuliah lain dengan topik yang terkait juga ditampilkan dalam hasil pencarian?
• Seberapa banyak hasil pencarian yang ingin ditampilkan?
• Apakah hasil pencarian menampilkan semua kuliah yang pernah ada termasuk yang sudah berlalu, atau yang sedang aktif atau berlangsung saja?
• Hasil pencarian ingin diurutkan berdasarkan apa? Populer, terbaru, atau gimana?
• Informasi apa saja yang ingin ditampilkan di hasil pencarian?

Dengan munculnya banyak pertanyaan tersebut, development team perlu banget berkolaborasi dengan klien melakukan percakapan untuk menjawab pertanyaan-pertanyaan yang muncul dari para developer, dan developer pun akhirnya bisa mendapatkan detail yang cukup untuk implementasi dari hasil percakapan tersebut.

3. User Story sebagai Confirmation
Melalui diskusi dengan klien, development team mendapatkan banyak detail dari suatu user story. Nah, selanjutnya detail tersebut perlu dituliskan secara sederhana untuk melengkapi deskripsi fungsionalitas yang juga sederhana. 🙂

User story sebagai Confirmation menuangkan detail dalam bentuk acceptance test atau sering disebut juga sebagai acceptance criteria. Acceptance test tersebut akan mengkonfirmasikan apa yang sebenarnya dimaksud dengan klien. Beberapa asumsi dan ekspektasi terkait suatu user story dapat dikomunikasikan melalui acceptance test.

Sebagai contoh, mari kita lihat kembali user story di atas dengan ID 02. Saya menuliskan beberapa kemungkinan acceptance test untuk user story tersebut.

ID: 02
Sebagai peserta, saya ingin mencari mata kuliah dengan memasukkan judul atau topik tertentu sehingga saya bisa menemukan kuliah yang mungkin saya minati

Acceptance Test:

• Coba suatu nilai yang cocok dengan judul mata kuliah
• Coba suatu nilai yang cocok dengan topik mata kuliah
• Coba suatu nilai yang cocok dengan judul dan topik mata kuliah
• Coba suatu nilai yang tidak cocok dengan mata kuliah manapun

Acceptance test di atas hanyalah awalan. Development team atau klien bisa menambah test yang baru atau mengurangi test yang sudah ada seiring perjalanan implementasi user story. Penambahan atau pengurangan ini dimungkinkan jika terdapat ekspektasi baru yang hadir karena sebelumnya tidak terpikirkan, atau karena ekspektasi yang sudah dituliskan sebelumnya sudah tidak relevan lagi saat ini.

Dengan acceptance test, masalah komunikasi antara development team dengan klien bisa diminimalisir. Acceptance test menangkap ekspektasi klien lalu menyampaikan ekspektasi tersebut ke developer. Acceptance test ini selanjutnya digunakan oleh developer sebagai panduan dan pengingat dalam implementasi suatu user story yang dipilih. Acceptance test ini pun digunakan oleh developer sebagai kriteria untuk menentukan apakah suatu user story sudah selesai diimplementasikan.

—

Ya, itulah sedikit tentang user story. Saat kamu mau menuliskan requirements ke dalam bentuk user story, jangan lupa tiga buah aspek penting dalam user story, yaitu Card, Conversation, dan Confirmation. Meskipun kita sudah menuliskan deskripsi fitur atau fungsi plus acceptance test-nya, jangan lupa hal terpenting dari user story, yaitu mendorong kolaborasi orang-orang yang terlibat di pengembangan software untuk selalu berdiskusi melakukan percakapan mengenai fungsionalitas yang ingin dibuat.

Tertarik menggunakan user story untuk project kamu? Atau kamu sudah punya pengalaman dengan user story atau ingin bertanya dan diskusi lebih lanjut? Let’s discuss. 😀

Happy learning!

 

Referensi:

1. Cohn, Mike. User Stories Applied: For Agile Software Development. Boston: Pearson Education, 2004. Print.
2. Ambler, Scott W., and Matthew Holitza. Agile for Dummies, IBM Limited Edition. Hoboken: John Wiley & Sons, 2012.

Selamat Datang di Inpensil

Assalamu’alaikum!
Hai yang di sana, selamat datang di Inpensil. 😀

Perkenalkan, nama saya Ardi. Sebagai perkenalan singkat, saya adalah seseorang yang antusias dengan yang namanya pengembangan software, baik dari sisi teknologi maupun prosesnya. Ketertarikan itu membuat saya akhirnya memutuskan kuliah lagi untuk belajar banyak hal mengenai software. Saat tulisan ini dibuat, saya merupakan mahasiswa di S2 Magister Teknologi Informasi (MTI) Universitas Indonesia. Yay, I love to learn new things. 🙂

Untuk kamu yang bertanya-tanya tentang blog apakah ini, Inpensil adalah sebuah blog yang didedikasikan untuk menulis hal-hal mengenai software process dan practice-nya sehari-hari untuk menghasilkan software yang lebih baik. Di sini saya akan membahas berbagai macam pendekatan pengembangan software mulai dari konsepnya, filosofi di baliknya, hingga practice-nya. Saya juga akan berbagi pengalaman saat mengembangkan software sehari-hari dan tantangan-tantangan yang dihadapi. Meski berbicara mengenai software, tulisan di Inpensil akan dikemas dalam bahasa yang ringan dan sederhana. Haha, mudah-mudahan.

Tulisan di Inpensil dibuat untuk siapapun yang pernah, sedang, atau akan terlibat di pengembangan software dan ingin proses pengembangan software-nya menjadi lebih baik, entah kamu berperan sebagai Software Developer, UI/UX Designer, Business Analyst, System Analyst, Product Manager, Project Manager, atau bahkan User atau Client. Melalui tulisan di Inpensil, saya bersemangat untuk berbagi apa yang saya ketahui dan pengalaman yang saya alami mengenai dunia software process dan practice-nya. Tulisan di Inpensil tidak hanya melihat dari sudut pandang process melainkan juga akan melihat dari sudut pandang manusia (people) yang terlibat dalam proses tersebut. Saya berharap tulisan dan diskusi di sini bisa membantu proses pengembangan software menjadi lebih baik dan juga lebih menyenangkan di organisasi kita masing-masing. Dengan pengetahuan mengenai software process yang mumpuni dan implementasinya yang sesuai dengan kondisi organisasi masing-masing, produk aplikasi yang dihasilkan dari proses pengembangan software yang baik adalah produk yang sesuai dengan kebutuhan pengguna dan berkualitas tinggi. Produk aplikasi tersebut pada akhirnya akan memberikan value bagi penggunanya. Dengan kata lain, produk aplikasi tersebut memiliki nilai manfaat bagi penggunanya dan juga memberikan kemudahan dalam kehidupan sehari-hari.

Sebagai gambaran, kira-kira topik apa aja sih yang akan dibahas di sini? Banyak topik terkini yang terkait dengan Agile yang ingin saya tuliskan seperti Scrum, XP (eXtreme Programming), User Story, Kanban, dan lainnya. Tidak hanya tentang Agile, saya juga ingin menuliskan tentang Lean Process, RUP (Rational Unified Process), Waterfall, Spiral, Use Case, bahkan juga Process Improvement seperti CMMI (Capacility Maturity Model Integration). Tidak lupa juga hal-hal yang berkaitan dengan testing process seperti TDD (Test-Driven Development) dan teamwork management. Ya apapun yang terkait dengan software process dan practice-nya deh. Haha.

Saat ini tulisan di blog ini ditulis oleh saya sendiri. Ke depannya mudah-mudahan ada penulis lain yang nimbrung menulis di blog ini. Jika kamu mau ikutan menyumbangkan tulisan di Inpensil atau sekedar berdiskusi dengan saya, boleh atuh kirim email ke ardi.alhaidar@gmail.com. Kamu juga bisa say hi di @ardialhaidar. xD

Mudah-mudahan konten yang ada di blog ini bermanfaat dan menginspirasi untuk melakukan perbaikan pada software process dan practice-nya di organisasi kita masing-masing. Ke depannya, semoga makin banyak organisasi yang memiliki proses pengembangan software yang baik dan juga menghasilkan produk aplikasi yang baik. So what do you think? silakan sampaikan di kolom komentar.

Happy learning!