Menggunakan Agile Spreadsheets untuk Estimasi Penemuan

Artikel ini menyertakan spreadsheet yang telah diformat sebelumnya untuk membantu Anda mengembangkan estimasi penemuan Agile. Ini juga mencakup informasi untuk membantu Anda mengikuti contoh unggulan. Anda dapat membuat salinan yang dapat diedit (File> Make a copy atau File> Download) dari template di sini.

Klien sering meminta saya untuk memberikan perkiraan Agile sebelum saya memiliki tim atau mengetahui persyaratan MVP. Pada tahap awal ini, saya tidak memiliki akses ke metrik tradisional seperti kecepatan, jumlah sprint, atau biaya tim untuk menghitung perkiraan tersebut. Tetapi klien menginginkan jawaban. Bisakah mereka meluncurkan produk hipotetis dalam dua atau enam bulan? Apakah itu layak untuk anggaran mereka (biasanya rendah)?

Masukkan spreadsheet Agile.

Spreadsheet adalah pilihan yang pas—tetapi sering diabaikan—untuk pola pikir Agile. Mereka adalah alat berteknologi rendah dan canggih yang mendorong kolaborasi. Yang mengatakan, pelanggan Anda mungkin tidak peduli apakah alat Anda "disetujui Agile" selama biaya dan kualitas produk memenuhi persyaratan mereka. Nilai sebenarnya dari spreadsheet terletak pada aksesibilitasnya ke manajer proyek dan pemangku kepentingan dari semua tingkat pengalaman.

Banyak alat manajemen proyek khusus memiliki kurva pembelajaran yang terlalu curam untuk pengguna yang tidak berpengalaman pada proyek yang bergerak cepat. Jadi, semakin mudah bagi klien, pemilik produk, dan pengembang untuk memperbarui persyaratan dan biaya tenaga kerja, semakin cepat Anda mencapai perkiraan yang realistis. Dengan spreadsheet yang telah diformat sebelumnya, manajer proyek dapat menyesuaikan nilai dan parameter untuk menunjukkan efek dari setiap sumber daya yang berfluktuasi atau garis waktu yang berubah.

Spreadsheet juga merupakan cara yang bagus untuk berbagi pengetahuan dengan kolega Anda. Spreadsheet yang saya gunakan berasal dari kolega Toptal, dan sejak itu saya telah membuat salinan dan memodifikasinya agar sesuai dengan kebutuhan saya. Saya mendorong Anda untuk melakukannya juga.

Dalam artikel ini, saya menunjukkan cara memberikan perkiraan penemuan yang berhasil yang memberdayakan klien dan pemangku kepentingan untuk menyelaraskan tujuan proyek dan melanjutkan pengembangan. Inilah cara mengisi kekosongan dan memberikan perkiraan tahap awal yang dapat Anda pertahankan.

Tangani Visi Produk dan Peta Jalan Terlebih Dahulu

Katakanlah klien Anda ingin mengembangkan situs kencan dengan anggaran tetap, tetapi detail produknya tidak jelas. Tanpa mengetahui biaya dan kecepatan tim, visi produk adalah tempat terbaik untuk memulai karena memerlukan pemangku kepentingan untuk menyetujui target desain dan mempromosikan transparansi di seluruh tim.

Saya menyukai format visi produk Scrum.org karena gaya naratifnya yang intuitif. Berikut tampilannya:

Setelah visi produk ditetapkan, Anda dapat menambahkan Product Roadmap di tab spreadsheet baru untuk memberi klien gambaran tentang jadwal proyek jangka panjang. Peta jalan harus mencantumkan tujuan, fitur utama, dan tenggat waktu untuk setiap versi peta jalan produk.

Versi peta jalan adalah edisi produk yang direncanakan, menghadap konsumen atau klien yang memandu lintasan pasarnya. Versi peta jalan pertama adalah produk yang dapat Anda debutkan di pasar. Versi peta jalan berikutnya mewakili rilis pasar dengan fitur-fitur baru yang menarik yang selaras dengan visi produk.

Untuk menggunakan Microsoft sebagai contoh: Windows 8 kemungkinan adalah versi peta jalan. Windows 10 adalah versi peta jalan lain yang menampilkan banyak fitur baru dan diinginkan.

Setelah visi produk dan peta jalan selesai, saatnya meminta klien untuk berkomitmen pada MVP.

Negosiasikan Fitur MVP Dengan Bagan Kendala Tiga Kali

Inilah saatnya untuk membentuk ekspektasi klien Anda seputar waktu dan biaya menggunakan bagan Kendala Tiga Kali:

Dalam pendekatan Waterfall, fitur tetap menentukan waktu dan biaya, dan pengembangan berlangsung sesuai dengan rencana proyek yang terperinci. Sebaliknya, biaya dan jadwal tetap Agile menentukan fitur produk, dan fitur ini terus diprioritaskan berdasarkan visi proyek yang lebih fleksibel.

Bagan Triple Constraint menunjukkan kepada klien bahwa memasukkan semua fitur yang diinginkan dalam rilis pertama akan meningkatkan waktu pengembangan dan biaya balon. Sebagai gantinya, bekerjalah dengan klien untuk memilih hanya fitur yang "harus dimiliki" untuk MVP dan tabel fitur yang tersisa untuk rilis mendatang.

Spreadsheet memudahkan untuk mengelompokkan dan menetapkan kembali fitur ke versi, rilis, dan prioritas yang berbeda berdasarkan kebutuhan perubahan klien, dan mereka langsung menampilkan biaya perubahan ini.

Saat Anda mengidentifikasi fitur MVP, mintalah bantuan pakar materi pelajaran (UKM) Anda untuk membuat daftar langkah-langkah proyek berdasarkan proyek serupa yang telah mereka kerjakan. Anda akan menggunakan langkah-langkah ini untuk membuat epos nanti. Setelah input tersebut siap, Anda dapat mulai membuat perkiraan.

Mulai Dengan Ukuran T-shirt

Untuk memulai backlog pertama, mintalah deskripsi detail fitur produk kepada pemilik produk, lalu tetapkan ukuran T-shirt untuk setiap fitur berdasarkan tingkat kesulitannya.

Ukuran kaos akan menunjukkan kompleksitas dan durasi relatif dari setiap tugas pengembangan sebelum Anda memiliki nilai absolut. Saat kita masuk lebih jauh ke dalam perencanaan proyek, kita akan mengubah ukuran relatif ini menjadi poin cerita dan jam kerja.

Misalnya, jika klien Anda ingin Anda mengembangkan serangkaian pop-up di situs kencan, itu akan memakan waktu tetapi langsung. Anda mungkin mencirikan kompleksitas tugas itu sebagai "Kecil" tetapi upayanya akan menjadi "Sedang." Anda bisa menyingkat ini sebagai "SM." Di sisi lain, mengembangkan koneksi back-end untuk API baru akan menjadi tugas yang lebih kompleks karena semua dokumentasi dan pengujian yang diperlukan. Keterampilan dan perhatian yang dibutuhkan untuk ini mungkin membuatnya menjadi "Besar" dalam upaya dan tingkat keterampilan: "LL."

Setelah Anda menyelesaikan ukuran T-shirt, Anda akan merasakan beban kerja relatif dan persyaratan keterampilan untuk setiap anggota tim di masa depan. Seorang ahli teknis dari tim pengembangan kemudian dapat membantu Anda menghubungkan ukuran T-shirt Anda dengan rentang jam dan poin cerita.

Tetapkan Parameter Anda

Sekarang Anda siap untuk menggunakan spreadsheet Anda dan menghitung perkiraan Anda. Mulailah dengan membuat tab Parameter. Ini akan berfungsi sebagai kunci untuk perhitungan Anda, dan nilai yang Anda masukkan di sini akan dimasukkan ke dalam rumus yang digunakan dalam Backlog/Kisah Pengguna dan Ringkasan Perkiraan berdasarkan Rilis.

Ini semua yang Anda perlukan di tab Parameter:

Mata uang. Di sinilah Anda memasukkan konversi mata uang. Misalnya, jika anggaran klien dalam real Brasil, Anda dapat memasukkan tingkat konversi saat ini untuk dolar atau euro.

Mulai tanggal. Tanggal mulai pengembangan yang diharapkan akan digunakan untuk membuat garis waktu proyek. Dalam setiap contoh, tanggal mulai kami adalah 25 Oktober.

Anggaran Awal. Anggaran memberikan batasan yang menunjukkan apakah semua fitur MVP cocok di dalamnya atau tidak.

Ukuran Kaos. Masukkan ukuran T-shirt Anda sebagai tabel, dan tetapkan poin cerita dan rentang jam untuk setiap kombinasi ukuran. Dalam contoh ini, kami menggunakan satu hingga dua jam untuk SS dan 33 hingga 48 jam untuk LL.

Ingatlah bahwa durasi sprint Anda akan membatasi jam ukuran T-shirt maksimum Anda. Jika sprint hanya satu minggu, ukuran terbesar tidak boleh melebihi 40 jam. Inilah sebabnya mengapa berkonsultasi dengan UKM sangat penting saat menetapkan ukuran T-shirt untuk tugas .

Tarif per Jam. Gunakan tabel ini untuk mendokumentasikan tingkat pembayaran untuk setiap peran. Jika pengembang back-end Anda memiliki tarif yang berbeda, gunakan rata-rata keduanya.

Atas. Alokasikan persentase dari total upaya proyek untuk tugas-tugas administratif seperti rapat status, sesi umpan balik, dan revisi proyek. Sepuluh persen (atau empat jam dari setiap minggu kerja peserta) adalah tempat yang baik untuk memulai, tetapi biaya overhead mungkin lebih tinggi untuk proyek yang lebih kompleks.

Kemungkinan. Ini menunjukkan potensi varians dalam perkiraan Anda. Dimulai dengan kontingensi 0% akan menunjukkan kepada Anda kasus terbaik (yaitu, tidak mungkin) anggaran dan garis waktu berdasarkan nilai yang telah Anda masukkan ke dalam spreadsheet. Kemudian dalam contoh kita, kita akan meningkatkan kontingensi ke varians urutan besarnya (ROM) kasar sebesar 50% untuk menunjukkan potensi biaya akhir yang tinggi dan durasi proyek. Kontingensi akan menyusut saat Anda mendapatkan angka yang lebih tepat.

Ukuran Setiap Rilis Dengan Epik

Kami mulai dengan ukuran kasar produk lengkap untuk memastikan kami tidak membuang waktu atau uang klien. Bergantung pada seberapa dekat ukurannya dengan anggaran dan tenggat waktu yang diusulkan, klien dapat memutuskan untuk meninggalkan proyek atau berinvestasi dalam perkiraan yang lebih rinci. Karena kami tidak memiliki banyak detail pada saat ini, kami memasukkan fitur utama sebagai epik di tab Backlog/User Stories. Kemudian, untuk setiap epik, kami memasukkan jumlah jam yang disarankan oleh UKM dan pemimpin pengembangan untuk setiap tumpukan pengembangan berdasarkan tabel ukuran T-shirt di tab Parameter.

Pertama, pilih kolom “EPIC?” dan pastikan hanya "Epik" yang dipilih.

Selanjutnya, tuliskan deskripsi epik dan masukkan jumlah jam untuk setiap kolom tumpukan pengembangan. Misalnya, epik "Koneksi Aman dan Login" akan memakan waktu sekitar delapan jam pengembangan UI, 40 untuk back end, dan seterusnya.

Perhatikan bahwa dalam kebanyakan kasus, sel di kolom “Titik” menampilkan “34*.” Jika Anda kembali ke tab Parameter, Anda akan melihat bahwa 34 poin sesuai dengan rentang per jam antara 33 dan 48 jam. Jumlah jam itu terlalu besar jika durasi sprint kita hanya satu minggu.

Setelah kami memiliki detail lebih lanjut, jam-jam ini perlu dikurangi, atau epos harus dipecah menjadi cerita yang lebih mudah dikelola. Namun, demi waktu, kami akan mengabaikan kolom Poin dan melanjutkan dengan perkiraan kasar.

Sekarang buka tab Estimasi Ringkasan berdasarkan Rilis. Di bagian atas spreadsheet, Anda akan melihat nilai “Overhead” dan “Kontinjensi” seperti yang ditentukan di tab Parameter. Ada juga tombol yang dapat Anda pilih untuk menampilkan perkiraan berdasarkan epos atau cerita pengguna.

Karena kami belum memiliki cerita pengguna untuk ditampilkan, periksa tombol untuk "Mode Epik."

Anda sekarang dapat melihat biaya kasar dan jadwal untuk MVP serta fitur dan pembaruan yang kurang mendesak di rilis mendatang (R3 dan R4). Dalam contoh ini, rilis kedua (R2) kosong karena pelanggan telah meminta agar semua epik MVP diluncurkan di versi pertama.

Anda sekarang dapat melihat biaya agregat paling optimis: $28.810. Angka ini merupakan penjumlahan dari biaya setiap rilis dari MVP hingga R4.

Kami juga memiliki perkiraan garis waktu terpendek untuk pengiriman produk, yang sesuai dengan tanggal penyelesaian terakhir di tumpukan pengembangan R4. Manajer proyek menyebut tumpukan pengembangan yang lebih lambat ini sebagai "jalur kritis" karena mereka menentukan kecepatan seluruh rilis.

Dalam hal ini, jalur kritis adalah pengembangan front-end, dengan tanggal penyelesaian 31 Januari.

Sekarang saatnya menyesuaikan parameter untuk mensimulasikan anggaran kasus terburuk dan garis waktu terlama.

Sesuaikan Kontingensi menjadi 50%

Kami masih tahu relatif sedikit tentang persyaratan upaya dan keahlian untuk produk, jadi kami akan menambahkan kontingensi ROM sebesar 50% di tab Parameter. Kontingensi akan berkurang saat kita mempelajari lebih detail tentang proyek.

Sekali lagi, inilah perkiraan total proyek pada kontingensi 0%.

Dan ini dia di 50% kontingensi.

Itu berarti bahwa perkiraan ROM untuk keseluruhan proyek adalah antara $28.810 dan $41.860. Dalam kasus terbaik dan terburuk, anggaran klien sebesar $20.000 tidak akan cukup untuk memasukkan semua fitur dalam daftar keinginan mereka.

Tanggal penyelesaian proyek penuh pada kontingensi 50% sekarang jatuh pada 14 Maret, enam minggu lebih lambat dari tanggal penyelesaian kontinjensi 0%.

Sementara itu, MVP akan siap pada 10 Januari.

Alih-alih meninggalkan proyek, klien meminta perkiraan yang lebih rinci untuk melihat apakah proyek tersebut dapat mendekati anggaran target mereka pada waktu yang lebih singkat.

Prioritaskan Ulang untuk Memenuhi Tenggat Waktu

Misalkan klien menetapkan tanggal target 25 Desember untuk MVP, dua bulan dari kickoff 25 Oktober.

Untuk meningkatkan tanggal penyelesaian MVP 10 Januari saat ini, klien setuju untuk menunda dua epik MVP hingga rilis berikutnya (R2).

Spreadsheet menghitung efek kaskade dari penyesuaian ini. Dalam hal ini, timeline MVP dipersingkat menjadi 27 Desember. Pengembangan front-end dan back-end adalah jalur kritis dalam simulasi ini karena akan memakan waktu paling lama untuk diselesaikan.

Berdasarkan informasi ini, Anda mungkin memutuskan untuk menambahkan dua pengembang lain untuk menyelaraskan tanggal penyelesaian front-end dan back-end dengan tumpukan pengembangan lainnya. Untuk melakukan ini, tingkatkan jam dari 40 menjadi 80 di baris "Jam per minggu" MVP.

Tumpukan pengembangan front-end dan back-end sekarang selesai pada bulan November, dan QA menjadi jalur kritis baru (dengan tanggal penyelesaian 20 Desember). Perhatikan bahwa biaya tidak berubah. Itu karena total jam kerja di setiap tumpukan tetap sama. Alih-alih satu pengembang bekerja selama dua minggu (80 jam), dua pengembang bekerja selama satu minggu (80 jam).

Spreadsheet juga menjelaskan perbedaan antara pekerjaan penuh dan paruh waktu. Misalkan pengembang UI akan bekerja paruh waktu. Kami dapat mengubah UI "Jam Desain per minggu" menjadi 20 untuk mensimulasikan keterlambatan pengiriman.

Pada jadwal full-time, UX/UI akan selesai pada 29 November.

Pada jadwal paruh waktu, UX/UI akan selesai pada 27 Desember.

Sekali lagi, biayanya tidak berubah, tetapi UX/UI menjadi jalur kritis baru, memperpanjang garis waktu untuk MVP hingga 27 Desember.

Anda dapat melanjutkan pendekatan coba-coba ini sampai Anda tiba di jalur kritis yang dapat diterima dengan sumber daya Anda dan tenggat waktu klien. Setelah tenggat waktu yang tepat tersedia, saatnya untuk mulai menyempurnakan perkiraan Anda.

Perbaiki Perkiraan Anda Dengan Cerita Pengguna

Karena perkiraan kontinjensi 50% berada di luar anggaran klien, ada baiknya menyempurnakan variabel Anda sehingga Anda dapat menurunkan kontinjensi dan mendapatkan perkiraan yang lebih realistis.

Untuk melakukan ini, bekerjalah dengan pengembang dan UKM Anda untuk memecah epik Anda menjadi cerita pengguna yang mendetail. Cerita didefinisikan lebih baik daripada epos, jadi kami dapat mengukurnya dengan lebih akurat.

Selanjutnya, sesuaikan nilai di tab Parameter Anda berdasarkan informasi baru. Misalnya, UKM dan tim pengembangan Anda mungkin memiliki set tarif yang lebih akurat untuk setiap peran dan mungkin juga ingin menyesuaikan ukuran T-shirt dan pembagian poin. Dengan adanya parameter baru tersebut, Anda dapat lebih percaya diri dalam perhitungan Anda dan menurunkan kemungkinan menjadi 25%.

Mari kita lihat bagaimana kami memecah epos menjadi cerita pengguna yang lebih kecil dan lebih detail:

Berbeda dengan estimasi epic yang mengharuskan memasukkan estimasi jam untuk setiap stack secara manual, estimasi story menggunakan T-shirt sizing sebagai jalan pintas. Di sinilah ukuran T-shirt yang Anda masukkan di tab Parameter berguna.

Di bawah “Ukuran Kaos” di tab Backlog/Kisah Pengguna, masukkan kombinasi ukuran yang ditetapkan pengembang dan UKM Anda ke tumpukan mereka untuk setiap cerita. Dari sana, rumus spreadsheet akan otomatis mengisi jam yang sesuai dari tab Parameter. Ingatlah bahwa ukuran terbesar, LL, harus tetap di bawah 34 poin untuk memastikannya dapat diselesaikan dalam durasi sprint yang Anda setujui. Cerita apa pun yang masih memberi peringkat 34 poin atau lebih tinggi perlu dibagi lagi.

Setelah Anda memastikan bahwa kurang dari 34 poin ditetapkan ke semua cerita, hapus centang tombol "Mode Epik" pada tab Perkirakan Ringkasan berdasarkan Rilis untuk hanya melihat "Kisah".

Sekarang Anda akan melihat serangkaian angka baru:

Setelah merinci semua tugas dan tetap berpegang pada fitur MVP saja, timeline dan biaya sekarang sesuai dengan kebutuhan klien. Karena saldonya sesuai dengan anggaran mereka, klien memutuskan untuk melanjutkan dengan MVP dan mengujinya sebelum melakukan rilis tambahan.

Jadikan Itu Milikmu

Spreadsheet mudah digunakan, dan dengan beberapa pengetahuan dasar tentang rumus (tidak perlu makro), Anda dapat menyesuaikannya dengan hampir semua kebutuhan. Jika pengetahuan Excel Anda berkarat, kursus online di Udemy dan edX akan membantu Anda memoles keterampilan ini.

Artikel ini membahas estimasi penemuan, tetapi Anda dapat menggunakan spreadsheet yang sama untuk menghasilkan grafik burnup/burndown, menyesuaikan garis waktu, dan menghitung perkiraan berdasarkan kecepatan dan sprint untuk tahap selanjutnya. Saya menggunakan spreadsheet khusus saya untuk melengkapi aplikasi, seperti Jira, Asana, dan Trello, dan mempertahankan bahwa mereka adalah alat yang ampuh dalam kit manajemen proyek saya. Saya harap mereka terbukti sama berguna dan serbaguna untuk Anda.

Apakah Anda lebih suka spreadsheet khusus daripada alat manajemen proyek yang siap pakai? Beri tahu kami mengapa atau mengapa tidak di komentar.