Cost of Delay dalam Software Development: Berapa Nilai Bisnis yang Hilang karena Menunda?

Enterprise hampir tidak pernah kekurangan ide teknologi. Ada legacy system yang perlu diperbarui, workflow yang masih manual, integration yang belum tersedia, security issue yang perlu diperbaiki, customer journey yang dapat disederhanakan, data yang perlu disatukan, serta berbagai peluang automation dan AI. Masalahnya bukan menentukan apakah seluruh initiative tersebut memiliki value. Sebagian besar memang memiliki alasan yang masuk akal. Masalah sebenarnya adalah capacity, budget, dan waktu tidak cukup untuk mengerjakan semuanya secara bersamaan.

Ketika kondisi ini terjadi, prioritization sering kembali pada metode yang terlihat praktis. Project dengan sponsor paling senior bergerak lebih dahulu. Feature yang dianggap urgent mendapat jalur cepat. Initiative dengan effort paling kecil dipilih karena mudah diselesaikan. Atau organisasi membuat scoring berdasarkan business value dan technical complexity. Seluruh pendekatan tersebut dapat membantu, tetapi ada satu variabel yang mudah terlewat: apa yang terjadi terhadap bisnis selama initiative tersebut menunggu?

Dua initiative dapat memiliki expected value yang sama, tetapi memiliki urgency ekonomi yang sangat berbeda. Initiative pertama mungkin tetap menghasilkan value yang hampir sama meskipun baru dilakukan enam bulan lagi. Initiative kedua kehilangan opportunity, membiarkan operational leakage terus terjadi, atau membuat risk exposure terus bertambah setiap minggu penundaan.

Di sinilah konsep Cost of Delay menjadi penting.

Scaled Agile Framework mendefinisikan Cost of Delay sebagai uang atau value yang hilang ketika suatu pekerjaan ditunda atau tidak dilakukan selama periode tertentu. Dalam pendekatan Weighted Shortest Job First atau WSJF, Cost of Delay bahkan digunakan bersama durasi pekerjaan untuk membantu menentukan sequence yang memberikan economic benefit lebih tinggi. Scaled Agile Framework

Namun bagi enterprise, nilai terbesar Cost of Delay bukan pada rumusnya. Nilainya terletak pada perubahan pertanyaan:

Bukan hanya “berapa besar value project ini?”

Tetapi:

“Berapa banyak value yang terus hilang setiap kali kita memutuskan menunggu?”

Apa Itu Cost of Delay?

Cost of Delay adalah konsekuensi ekonomi atau bisnis dari terlambat memperoleh suatu outcome. Dalam konteks software development, ia mengukur value yang tidak dapat direalisasikan selama technology intervention yang dibutuhkan belum tersedia.

Misalnya automation diperkirakan dapat mengurangi pekerjaan manual secara signifikan. Jika automation baru tersedia enam bulan lagi, organisasi bukan hanya membayar biaya development ketika project dimulai. Selama enam bulan tersebut, manual effort tetap terjadi, backlog mungkin terus bertambah, dan capacity yang seharusnya dapat digunakan untuk pekerjaan lain tetap terkunci.

Contoh lain adalah integration. Perusahaan memiliki ERP dan CRM yang belum terhubung sehingga employee melakukan reconciliation setiap hari. Nilai integration tidak hanya berasal dari future efficiency. Setiap minggu implementation ditunda, perusahaan terus membayar current inefficiency.

Dengan demikian, Cost of Delay dapat dipahami sebagai:

Value yang seharusnya dapat diperoleh lebih awal tetapi belum terjadi karena intervention belum tersedia.

Namun value tersebut tidak selalu revenue. Ia dapat berupa cost, operational capacity, risk reduction, customer opportunity, learning, compliance exposure, atau strategic option.

Karena itu, Cost of Delay jauh lebih luas dibandingkan pertanyaan:

“Berapa revenue yang hilang jika feature terlambat?”

Cost of Delay Berbeda dari Cost of Doing Nothing

Crocodic sebelumnya sudah membahas Cost of Doing Nothing pada modernisasi legacy system. Keduanya memiliki hubungan, tetapi sebaiknya tidak digunakan untuk intent yang sama.

Cost of Doing Nothing lebih cocok menjawab keputusan strategis:

Apa konsekuensinya jika perusahaan sama sekali tidak melakukan modernization atau intervention tertentu?

Cost of Delay lebih cocok menjawab sequencing:

Jika intervention memang layak dilakukan, apa konsekuensinya jika kita melakukan initiative A sekarang dan initiative B tiga bulan lagi?

Perbedaannya penting karena enterprise jarang menghadapi pilihan sederhana antara “melakukan” dan “tidak melakukan”. Yang lebih umum adalah memiliki sepuluh initiative bernilai tetapi hanya mampu menjalankan tiga dalam quarter berikutnya.

Cost of Delay membantu menentukan urutan.

Dengan kata lain:

Cost of Doing Nothing membantu menentukan apakah action diperlukan.
Cost of Delay membantu menentukan kapan action tersebut seharusnya dilakukan relatif terhadap action lain.

Business Value Saja Belum Cukup untuk Menentukan Prioritas

Bayangkan dua project masing-masing diperkirakan menghasilkan value yang besar.

Project A adalah reporting platform yang dapat meningkatkan management visibility dan menghasilkan improvement jangka panjang. Namun jika dilakukan tiga bulan kemudian, expected benefit-nya relatif tidak berubah.

Project B mengotomasi process yang saat ini menghasilkan operational leakage setiap hari. Semakin lama project tersebut ditunda, semakin besar accumulated leakage.

Jika prioritization hanya melihat total expected value, keduanya dapat terlihat hampir sama. Namun jika waktu dimasukkan, Project B memiliki urgency ekonomi lebih besar.

Inilah alasan Cost of Delay tidak identik dengan business value.

Business value bertanya:

“Berapa besar manfaat jika initiative berhasil?”

Cost of Delay bertanya:

“Apa yang hilang selama manfaat tersebut belum tersedia?”

McKinsey menempatkan backlog prioritization, funding, product-management practices, dan technical-debt management sebagai beberapa capability dengan gap terbesar antara organisasi yang lebih matang dan kurang matang dalam product operating model. Mereka juga mendorong backlog yang selaras dengan business goals dan funding yang dikaitkan dengan measurable goals. McKinsey & Company

Artinya, prioritas teknologi tidak cukup ditentukan berdasarkan apakah sesuatu valuable. Enterprise juga perlu memahami timing of value.

Crocodic Cost of Delay Framework

Dalam pendekatan business-impact-oriented Crocodic, Cost of Delay dapat dilihat melalui chain:

Business Problem → Current Impact → Value at Stake → Delay Window → Value Decay → Intervention → Time-to-Value → Priority

Business Problem menentukan kondisi yang perlu diperbaiki. Current Impact mengukur consequence yang sudah terjadi sekarang. Value at Stake menjelaskan value yang dapat dipulihkan, dilindungi, atau diciptakan. Delay Window menunjukkan berapa lama initiative berpotensi tertunda. Value Decay melihat bagaimana consequence berubah seiring waktu. Setelah itu barulah Intervention dibandingkan dengan effort, dependency, dan Time-to-Value sebelum priority ditentukan.

Framework tersebut menghindari satu kesalahan umum: menganggap semua value memiliki hubungan yang linear terhadap waktu.

Tidak semuanya demikian.

Ada initiative yang setiap bulan keterlambatannya memiliki impact relatif sama.

Ada yang memiliki hard deadline sehingga delay satu minggu setelah tanggal tertentu sangat mahal.

Ada yang menjadi semakin mahal karena problem terus membesar.

Ada pula opportunity yang nilainya justru menurun jika window pasar terlewat.

Karena itu, Cost of Delay bukan sekadar menambahkan label high, medium, low urgency. Enterprise perlu memahami bagaimana value berubah terhadap waktu.

Tidak Semua Cost of Delay Berbentuk Revenue

Ketika istilah “economic prioritization” digunakan, organisasi sering mencoba mengubah setiap initiative menjadi nilai rupiah. Pendekatan tersebut berguna bila attribution cukup kuat, tetapi tidak selalu diperlukan atau bahkan tepat.

Cost of Delay dapat muncul dalam beberapa bentuk.

Ini membuat Cost of Delay relevan bahkan untuk internal software yang tidak menghasilkan revenue langsung.

Misalnya software maintenance membantu menurunkan unplanned downtime. Value-nya dapat berupa risk reduction dan protected operational capacity. API modernization dapat membuka future integration. Observability dapat mengurangi diagnosis time ketika system mengalami incident.

Deloitte menekankan bahwa technology value perlu dibaca melalui business strategy, growth, stakeholder value, dan outcome, bukan hanya traditional IT performance. Mereka juga menyarankan technology investment dikelola sebagai portfolio sehingga value, risk, dan reward dapat dibandingkan. Deloitte

Bentuk Cost of Delay Bisa Berbeda Sepanjang Waktu

Salah satu alasan Cost of Delay sulit dinilai adalah nilai waktu tidak selalu berbentuk garis lurus.

Initiative A mungkin kehilangan value secara konstan: setiap bulan perusahaan terus membayar manual processing yang hampir sama.

Initiative B dapat memiliki deadline. Sebelum regulasi berlaku, delay mungkin masih manageable. Setelah deadline, perusahaan menghadapi compliance exposure atau operational restriction.

Initiative C memiliki market window. Nilainya sangat tinggi jika diluncurkan sebelum competitor atau seasonal opportunity, lalu turun cepat setelah window tersebut lewat.

Initiative D justru memiliki accelerating cost. Technical debt membuat setiap release semakin sulit sehingga setiap bulan penundaan memperbesar cost perubahan berikutnya.

Karena itu, Crocodic dapat melihat setidaknya empat pola:

Constant Delay Cost — impact relatif sama per periode.

Deadline-Driven Delay — consequence melonjak setelah tanggal tertentu.

Accelerating Delay — problem membesar semakin lama tidak ditangani.

Opportunity Decay — potential value berkurang ketika market atau strategic window tertutup.

Memahami bentuk ini lebih penting daripada memaksakan satu formula ke seluruh project.

Cara Menghitung Cost of Delay tanpa Membuat False Precision

Enterprise tidak selalu memiliki data sempurna. Karena itu, Cost of Delay tidak harus dimulai dengan kalkulasi rupiah hingga digit terakhir.

Justru fake precision dapat berbahaya. Jika sebuah project diberi nilai “Rp1,27 miliar per bulan” berdasarkan banyak assumption yang lemah, angka tersebut terlihat objektif padahal uncertainty-nya tinggi.

Pendekatan yang lebih sehat adalah memulai dengan komponen yang dapat dibuktikan.

Jika process manual menggunakan sejumlah jam kerja setiap bulan, gunakan baseline tersebut. Jika customer opportunity dapat ditelusuri dari transaction data, gunakan historical evidence. Jika risk tidak dapat diubah menjadi expected financial loss dengan cukup confidence, gunakan relative risk scoring dan jelaskan assumption-nya.

Crocodic dapat menggunakan tiga level evidence:

Measured — berasal dari operational data yang memang tersedia.

Estimated — dihitung berdasarkan assumption yang masih cukup kuat.

Strategic / Relative — sulit diubah menjadi monetary value tetapi dapat dibandingkan dari business criticality.

Tujuannya bukan menghasilkan angka sempurna.

Tujuannya adalah membuat management dapat membedakan:

initiative yang relatif aman ditunda

dengan

initiative yang setiap bulan penundaannya memiliki consequence material.

Cost of Delay Harus Dibandingkan dengan Durasi Pekerjaan

Mengetahui initiative dengan Cost of Delay terbesar belum otomatis menyelesaikan sequencing problem.

Bayangkan dua initiative.

Project A memiliki Cost of Delay tinggi, tetapi membutuhkan waktu satu tahun.

Project B memiliki Cost of Delay sedikit lebih rendah tetapi dapat selesai dalam satu bulan.

Dalam kondisi tertentu, mengerjakan Project B terlebih dahulu dapat menghasilkan economic return lebih cepat sebelum capacity berpindah ke Project A.

Inilah prinsip di balik Cost of Delay Divided by Duration dan WSJF. SAFe menggunakan relative Cost of Delay dibandingkan dengan relative job duration untuk membantu sequencing backlog berdasarkan economic benefit. Scaled Agile Framework

Secara konseptual:

Priority ≈ Cost of Delay ÷ Duration

Namun enterprise tidak harus mengadopsi WSJF secara literal untuk memperoleh manfaatnya.

Pesan yang lebih penting adalah:

value dan urgency perlu dibandingkan dengan waktu yang dibutuhkan untuk memperoleh value tersebut.

Initiative bernilai besar yang membutuhkan tiga tahun berbeda secara economics dengan initiative bernilai cukup besar yang dapat mulai menghasilkan impact dalam empat minggu.

Di sinilah Cost of Delay berhubungan dengan Time-to-Value.

Jangan Menggunakan Cost of Delay untuk Mengoptimalkan Quick Win Saja

Ada risiko ketika organisasi terlalu bersemangat pada formula seperti Cost of Delay ÷ Duration: project kecil dan cepat dapat terus memenangkan prioritization, sementara foundation work berjangka panjang terus ditunda.

Ini bukan tujuan framework.

Beberapa initiative memiliki strategic enablement value yang sulit terlihat dalam short-term calculation. Modernisasi identity, integration architecture, data governance, automated testing, security controls, dan platform capability dapat membutuhkan investasi besar tetapi menjadi dependency bagi banyak future outcomes.

Jika seluruhnya kalah terhadap quick win, enterprise akan terus mengoptimalkan local efficiency sambil membiarkan structural constraint membesar.

Karena itu, Cost of Delay perlu dibaca bersama:

Business Impact, Strategic Enablement, Risk, Dependency, Time-to-Value, dan Confidence.

Misalnya API platform tidak memberikan direct revenue pada bulan pertama. Namun jika lima initiative bernilai tinggi tidak dapat dilakukan tanpa integration capability tersebut, delay terhadap platform sebenarnya memperlambat seluruh downstream value.

Di sini dependency menciptakan indirect Cost of Delay.

Dependency Dapat Membuat Cost of Delay Lebih Besar daripada yang Terlihat

Project sering diprioritaskan seolah-olah berdiri sendiri. Dalam enterprise architecture, hal tersebut jarang benar.

Master data improvement dapat menjadi dependency bagi automation.

Identity modernization dapat menjadi dependency bagi Zero Trust, customer portal, dan AI Agent.

System integration dapat menjadi dependency bagi real-time reporting dan automated workflow.

Jika foundational initiative ditunda, consequence-nya bukan hanya value initiative tersebut yang terlambat. Semua project yang bergantung padanya ikut tertunda.

Karena itu, dependency mapping perlu masuk dalam prioritization.

Crocodic sudah membahas portfolio sequencing melalui Digital Transformation Roadmap, yang tercatat dalam inventory saat ini. Cost of Delay memberikan layer ekonomi tambahan: initiative mana yang menahan value lain ketika terus diletakkan di belakang?

Pada kondisi tersebut, Cost of Delay dapat dilihat sebagai:

Direct Delay Cost + Downstream Delay Cost

Tidak harus dihitung menjadi satu angka, tetapi dependency-nya harus terlihat saat decision dibuat.

Security dan Risk Reduction Juga Memiliki Cost of Delay

Salah satu area yang sering sulit dibandingkan dengan revenue-generating feature adalah security.

Feature bisnis dapat menjanjikan revenue atau efficiency. Security initiative sering terlihat “tidak menghasilkan apa-apa” selama incident tidak terjadi.

Akibatnya, security remediation mudah terus turun di backlog.

Cost of Delay membantu memperbaiki framing tersebut.

Jika vulnerability terdapat pada critical internet-facing system, setiap periode remediation ditunda berarti risk exposure tetap terbuka. Nilai yang dipertaruhkan mungkin sulit dihitung sebagai direct monthly loss, tetapi consequence dari delay tetap nyata.

Hal yang sama berlaku pada compliance, resilience, backup, atau unsupported infrastructure.

Di sini, Cost of Delay bukan revenue yang hilang.

Ia berupa periode tambahan ketika enterprise tetap berada pada risk posture yang tidak diinginkan.

Karena itu, Crocodic tidak menyarankan memaksakan security initiative menjadi angka revenue palsu. Lebih baik menggunakan relative risk, business criticality, exposure, deadline, dan consequence sebagai bagian dari prioritization.

Cost of Delay Membuat Backlog Menjadi Economic Queue

Backlog sering terlihat seperti daftar pekerjaan.

Padahal dari perspektif Cost of Delay, backlog adalah queue of unrealized value.

Setiap item yang menunggu berarti ada outcome yang belum terjadi. Sebagian hanya menunggu tanpa consequence besar. Sebagian lainnya terus membakar value.

Scrum.org menggunakan framing serupa dengan menekankan bahwa pekerjaan yang menunggu dalam product-development queue memiliki economic consequence karena value, learning, atau opportunity belum terealisasi. Scrum.org

Cara berpikir ini mengubah fokus management.

Traditional question:

“Berapa banyak item yang sudah selesai?”

Cost-of-Delay question:

“Item apa yang masih menunggu dan berapa mahal waiting tersebut?”

Ini juga menjelaskan mengapa menjalankan terlalu banyak initiative secara bersamaan dapat menjadi counterproductive. Semua project terlihat aktif, tetapi semakin banyak dependency, context switching, dan queue antar-team dapat membuat value seluruh portfolio muncul lebih lambat.

Sometimes the fastest way to create value is not starting more work.

It is finishing the work whose delay is most expensive.

Cost of Delay dan Opportunity Cost Harus Dibaca Bersama

Setiap prioritas berarti ada sesuatu yang tidak diprioritaskan.

Jika engineering team menghabiskan tiga bulan pada Project A, enterprise bukan hanya membayar cost Project A. Ia juga menerima consequence karena Project B dan C baru dapat bergerak setelahnya.

Inilah opportunity cost dari prioritization.

Karena itu, pertanyaan sebaiknya bukan:

“Apakah Project A layak?”

Tetapi:

“Apakah Project A lebih layak dilakukan sekarang dibandingkan alternative investment lain yang juga menunggu?”

Perspektif ini sangat relevan terhadap technology investment. Deloitte mendorong portfolio approach terhadap investment sehingga CIO dan business leader dapat membandingkan value, risk, reward, dan strategic alignment, bukan mengevaluasi investment secara terisolasi. Deloitte

Crocodic juga sudah memiliki pembahasan mengenai Investasi Software Enterprise dan Budget Software Enterprise: New Build vs Repeat Investment. Cost of Delay memperkuat perspektif tersebut dengan memasukkan satu dimensi tambahan: time sensitivity of value. Artikel-artikel investasi tersebut juga tercatat dalam inventory Crocodic saat ini.

Hati-Hati Mengubah Semua Hal Menjadi “Urgent”

Begitu Cost of Delay digunakan, terdapat incentive baru: setiap stakeholder ingin menunjukkan bahwa project-nya memiliki Cost of Delay tinggi.

Sales mengatakan revenue terancam.

Operations mengatakan process sangat inefficient.

Finance mengatakan reconciliation critical.

IT mengatakan technical debt semakin besar.

Security mengatakan risk exposure tinggi.

Semua argumen mungkin valid, tetapi jika semuanya high urgency, framework kehilangan value.

Karena itu, estimate perlu diuji dengan evidence:

Apa baseline consequence yang memang terjadi sekarang?

Apa yang berubah jika ditunda satu bulan?

Apakah consequence benar-benar time-sensitive atau hanya total value yang besar?

Apakah terdapat deadline nyata?

Apakah value dapat dipulihkan nanti atau benar-benar hilang?

Pertanyaan terakhir sangat penting.

Jika Rp100 juta benefit hanya terlambat tiga bulan tetapi tetap dapat direalisasikan penuh setelahnya, consequence berbeda dari Rp100 juta opportunity yang hilang permanen setelah market window berakhir.

Cost of Delay perlu membedakan delayed value dengan destroyed value.

Cost of Delay Tidak Boleh Dihitung tanpa Adoption

Kesalahan lain adalah menganggap value mulai muncul pada tanggal software go-live.

Padahal system yang sudah production belum tentu langsung menghasilkan impact. User perlu mengadopsi, process berubah, data stabil, atau business operation menyesuaikan.

Jika development selesai dalam dua bulan tetapi adoption membutuhkan enam bulan, real Cost of Delay tidak berhenti di deployment.

Karena itu, Crocodic melihat priority melalui:

Delay to Start + Delivery Time + Adoption Lag + Time-to-Impact

Bukan hanya:

Development Duration

Hal ini penting dalam membandingkan intervention. Solution A mungkin lebih cepat dibangun tetapi sangat sulit diadopsi. Solution B membutuhkan sedikit lebih lama tetapi dapat langsung menyatu dengan current workflow.

Jika objective-nya mempercepat value, architecture dan experience decision perlu mempertimbangkan seluruh path to impact, bukan kecepatan coding saja.

AI Membuat Cost of Delay Semakin Penting—Bukan Kurang Penting

AI-assisted software development berpotensi menurunkan effort pada banyak aktivitas engineering. Code generation, testing assistance, documentation, dan prototyping dapat membuat sejumlah capability lebih cepat dibangun.

Pada pandangan pertama, ini dapat membuat prioritization terasa kurang penting: jika semuanya semakin cepat, mengapa tidak membangun lebih banyak?

Justru sebaliknya.

Ketika cost of production turun, cost of choosing the wrong thing dapat menjadi proportionally lebih besar. Enterprise dapat menghasilkan lebih banyak feature, experiment, automation, dan AI capability daripada sebelumnya. Backlog tidak hilang; kemungkinan justru bertambah.

Management kemudian membutuhkan discipline yang lebih kuat untuk menentukan mana yang perlu bergerak sekarang.

Gartner pada 2026 juga mulai mendorong prioritization teknologi yang lebih dekat dengan measurable business outcomes; misalnya research tentang data and analytics menekankan perlunya proses prioritization berdasarkan measurable business outcomes, sementara guidance cloud migration menyoroti business-focused sequencing untuk mempercepat time-to-value. Gartner

Kecepatan delivery karena itu tidak menghilangkan economics of delay.

Ia membuat economics tersebut semakin penting.

Crocodic Perspective: Priority Ditentukan Bukan Hanya oleh Value, tetapi oleh Value yang Membusuk karena Waktu

Dalam perspective Crocodic, business-impact-oriented development perlu melihat backlog sebagai investment portfolio.

Setiap initiative memiliki:

Expected Impact

Cost of Delay

Time-to-Value

Confidence

Dependency

Risk

dan Delivery Effort.

Cost of Delay memberikan dimensi yang sering hilang: berapa sensitif business value terhadap waktu?

Framework Crocodic dapat diringkas:

Business Problem → Current Impact → Value at Stake → Delay Window → Value Decay → Intervention → Time-to-Value → Priority

Kemudian ketika beberapa initiative perlu dibandingkan:

Priority = Business Impact + Cost of Delay + Time-to-Value + Confidence + Dependency + Risk

Bukan mathematical formula yang perlu diberi bobot universal, tetapi decision lens agar enterprise tidak memilih berdasarkan loudest stakeholder atau shortest feature list.

Scaled Agile menggunakan Cost of Delay dan duration dalam WSJF untuk economic sequencing. McKinsey menempatkan backlog prioritization dan funding sebagai capability penting product operating model. Deloitte mendorong portfolio-based technology investment yang terhubung dengan business strategy dan outcome. Scaled Agile Framework

Dalam Crocodic, prinsip tersebut diterjemahkan lebih sederhana:

Sebuah initiative tidak menjadi prioritas hanya karena valuable. Ia menjadi prioritas ketika menundanya membuat perusahaan kehilangan value yang lebih besar dibandingkan pilihan lain.

Kesimpulan

Enterprise tidak kekurangan pekerjaan teknologi. Yang langka adalah capacity untuk mengerjakan semuanya pada waktu yang sama.

Karena itu, business-impact-oriented development membutuhkan lebih dari daftar business value, effort, atau urgency. Organisasi perlu memahami economics of waiting.

Cost of Delay menjawab:

Apa yang terus hilang selama intervention belum tersedia?

Value tersebut dapat berupa revenue, efficiency, operational capacity, customer experience, risk reduction, strategic learning, atau capability yang membuka initiative lain.

Dalam framework Crocodic:

Business Problem → Current Impact → Value at Stake → Delay Window → Value Decay → Intervention → Time-to-Value → Priority

membantu menghubungkan backlog dengan consequence bisnis.

Namun Cost of Delay tidak perlu berubah menjadi financial model yang dipaksakan. Tidak semua value dapat dikonversi secara akurat menjadi rupiah. Relative scoring, evidence range, risk exposure, deadline, dan dependency tetap dapat digunakan selama assumption-nya transparan.

Yang terpenting adalah enterprise mulai membedakan dua initiative yang sering terlihat sama-sama “penting”:

yang bernilai tetapi masih aman menunggu,

dan

yang setiap minggu penundaannya membuat business value benar-benar hilang.

Karena pada akhirnya, prioritization bukan hanya keputusan mengenai apa yang akan dibangun.

Ia juga merupakan keputusan mengenai value mana yang dengan sadar kita biarkan terus menunggu.