Dalam software development, menentukan apakah sebuah feature selesai biasanya relatif jelas. Form dapat disubmit. Data berhasil disimpan. API memberikan response yang benar. User dengan role tertentu memiliki akses sesuai permission. Notification terkirim. Automated test berhasil. Performance memenuhi requirement. Setelah seluruh acceptance criteria terpenuhi, feature dapat dianggap selesai dan development bergerak ke pekerjaan berikutnya.
Masalah muncul ketika organisasi menggunakan definisi “selesai” tersebut untuk menjawab pertanyaan yang sebenarnya berbeda: apakah investment software ini berhasil?
Sebuah workflow automation dapat bekerja tanpa error tetapi cycle time tetap sama. Dashboard dapat menampilkan data real-time tetapi decision management tetap terlambat. AI assistant dapat digunakan ribuan kali tetapi manual workload tidak berkurang. Mobile application dapat memiliki adoption tinggi tetapi process yang menjadi alasan pembangunannya tetap menghasilkan bottleneck. Dalam semua kasus tersebut, software dapat dinyatakan berhasil secara teknis sementara business case-nya belum terbukti.
Di sinilah enterprise membutuhkan distinction antara Definition of Done dan apa yang dalam working framework Crocodic dapat disebut Definition of Value.
Scrum Guide 2020 mendefinisikan Definition of Done sebagai deskripsi formal mengenai kondisi sebuah Increment ketika telah memenuhi ukuran kualitas yang diperlukan untuk product. Ketika suatu Product Backlog Item memenuhi Definition of Done, sebuah Increment lahir. Tujuan konsep tersebut adalah menciptakan transparansi mengenai pekerjaan yang benar-benar selesai dan usable. Panduan Scrum Scrum Guide 2020
Itu merupakan discipline engineering yang sangat penting. Namun Definition of Done tidak dimaksudkan untuk membuktikan bahwa business outcome telah terealisasi.
Sebuah Increment dapat Done hari ini, sementara value-nya baru dapat diketahui beberapa minggu atau bulan kemudian.
Technical Acceptance dan Business Acceptance Menjawab Pertanyaan yang Berbeda
Traditional acceptance criteria umumnya berfokus pada behavior software. Jika user memilih action A, system harus melakukan B. Jika request memiliki kondisi tertentu, workflow harus menuju approver tertentu. Jika API menerima payload yang valid, data harus berhasil diproses. Criteria semacam ini sangat penting karena tanpa technical acceptance, engineering team tidak memiliki shared understanding mengenai behavior yang dianggap benar.
Namun business-impact-oriented development membutuhkan layer lain.
Misalnya perusahaan membangun automated approval routing karena approval cycle terlalu lambat. Technical acceptance dapat berbunyi: request dengan nominal tertentu otomatis diarahkan kepada approver sesuai matrix. Ketika routing tersebut berfungsi, feature layak diterima.
Tetapi alasan bisnis membangunnya mungkin adalah mengurangi average approval time dari kondisi baseline menuju target tertentu.
Maka terdapat dua pertanyaan berbeda:
Technical Acceptance: Apakah routing bekerja sesuai design?
Outcome Acceptance: Apakah keberadaan routing membantu approval cycle bergerak menuju target?
Kedua pertanyaan tersebut tidak boleh dicampur.
Jika technical acceptance gagal, engineering masih memiliki pekerjaan.
Jika technical acceptance berhasil tetapi outcome tidak berubah, diagnosis berikutnya berbeda. Bisa jadi user belum mengadopsi workflow baru. Bisa jadi root cause awal salah. Bisa jadi bottleneck berpindah ke tahap berikutnya. Bisa jadi automation hanya mengurangi sebagian kecil total waiting time.
Dengan memisahkan keduanya, perusahaan dapat menghindari kesimpulan sederhana bahwa software berhasil = business problem selesai.
Crocodic Outcome Acceptance Chain
Dalam pendekatan Crocodic, keberhasilan software dapat dilihat melalui empat layer:
Definition of Done → Definition of Adoption → Definition of Outcome → Definition of Value
Definition of Done memastikan technology intervention benar-benar bekerja, usable, secure, dan memenuhi quality requirement. Definition of Adoption melihat apakah intended user atau process benar-benar menggunakan capability tersebut. Definition of Outcome melihat apakah behavior atau operational performance yang menjadi target mulai berubah. Definition of Value menilai apakah perubahan tersebut cukup meaningful untuk menghasilkan benefit terhadap bisnis.
Keempat layer ini memberikan level evidence yang berbeda.
Bayangkan perusahaan membangun automated reconciliation.
Pada level Done, matching engine berhasil bekerja sesuai rule.
Pada level Adoption, majority transaction benar-benar diproses melalui automated flow.
Pada level Outcome, manual reconciliation volume turun.
Pada level Value, team dapat memproses transaction volume yang lebih besar tanpa kenaikan manual workload yang sebanding, atau operational cost benar-benar berkurang.
Sekarang organization dapat melihat dengan jelas di mana value chain berhenti.
Jika software Done tetapi Adoption rendah, masalah kemungkinan berada pada rollout, usability, process, atau change management.
Jika Adoption tinggi tetapi Outcome tidak berubah, hypothesis mengenai causal relationship perlu diperiksa.
Jika Outcome berubah tetapi Value belum material, mungkin magnitude improvement belum cukup besar atau downstream economics berbeda dari assumption awal.
Inilah keuntungan utama outcome-based acceptance: bukan hanya memberi score keberhasilan, tetapi membantu menemukan di layer mana expected value tidak terwujud.
Definition of Done Tidak Perlu Diubah Menjadi Business KPI
Penting untuk menjaga konsep ini agar tidak berlebihan. Kita tidak perlu memasukkan seluruh business KPI ke dalam Definition of Done engineering.
Misalnya sebuah feature dimaksudkan meningkatkan conversion. Engineering team tidak seharusnya dilarang menyatakan Increment Done sampai conversion meningkat, karena conversion dipengaruhi berbagai faktor di luar control developer.
Scrum Guide sendiri menempatkan Definition of Done sebagai quality state dari Increment, bukan measurement terhadap seluruh business impact. Panduan Scrum
Karena itu, Crocodic tidak menyarankan mengganti technical acceptance dengan outcome acceptance.
Yang dibutuhkan adalah dua level governance yang berbeda.
Software tetap membutuhkan Definition of Done agar quality tidak ambigu.
Investment membutuhkan Definition of Value agar business success juga tidak ambigu.
Prinsipnya:
Technical acceptance menentukan apakah software layak digunakan. Outcome acceptance menentukan apakah software layak dianggap berhasil sebagai business intervention.
Perbedaan ini penting terutama dalam kontrak vendor. Business KPI yang dipengaruhi pricing, organizational policy, user behavior, market condition, dan faktor lain tidak selalu adil dijadikan acceptance criteria contractual bagi engineering vendor.
Namun technology partner tetap perlu memahami outcome tersebut dan mendesain solution agar contribution terhadapnya dapat diukur.
Go-Live Adalah Milestone, Bukan Bukti Value
Go-live mudah menjadi pusat gravitasi project. Timeline dibuat menuju launch date. Management meminta progress sampai production. Vendor mengukur completion berdasarkan deployment. Setelah system berhasil digunakan, project dianggap selesai.
Dari perspective delivery, ini valid.
Dari perspective business impact, go-live justru sering menjadi awal measurement window.
Sebelum production, organisasi baru memiliki expected value. Setelah user menggunakan system dalam real workflow, evidence mulai tersedia.
Misalnya system baru dibuat untuk mengurangi order-processing cycle. Pada hari go-live, organization belum mengetahui apakah target tersebut benar-benar tercapai. User membutuhkan waktu beradaptasi. Volume transaction perlu cukup representatif. Exception mulai terlihat. Integration berjalan di kondisi riil. Operational behavior dapat berbeda dari testing environment.
Karena itu:
Go-Live ≠ Value Realized
Go-live membuktikan bahwa capability sudah tersedia.
Value realization membuktikan bahwa capability tersebut telah mengubah kondisi bisnis.
PMI menggunakan konsep serupa dalam Benefits Realization Management. Framework PMI mencakup identifikasi expected benefits, delivery benefits selama execution, dan sustainability benefit setelah project berakhir dan ownership berpindah ke business unit. Institute Manajemen Proyek PMI Benefits Realization Management Framework
Ini menjelaskan mengapa business case seharusnya tidak ditutup secara otomatis ketika deployment selesai.
Outcome Acceptance Membutuhkan Baseline yang Sudah Disepakati
Tidak mungkin menyatakan bahwa sesuatu membaik tanpa mengetahui kondisi sebelumnya.
Jika software dibuat untuk mempercepat processing time, perusahaan perlu mengetahui baseline. Jika dibuat untuk menurunkan manual work, manual effort sebelum implementation perlu dipahami. Jika objective-nya mengurangi error, error rate existing perlu diketahui.
Tanpa baseline, seluruh discussion setelah implementation menjadi subjektif.
Business mengatakan jauh lebih cepat.
User mengatakan sedikit lebih nyaman.
IT mengatakan system lebih modern.
Vendor menunjukkan seluruh feature selesai.
Namun tidak ada common reference untuk menentukan magnitude perubahan.
GOV.UK Service Manual merekomendasikan organisasi menetapkan baseline performance dan menilai perubahan service terhadap baseline tersebut. Guidance yang sama menyarankan measurement dirancang sejak service dibangun, bukan baru dipikirkan setelah implementation. GOV.UK GOV.UK — How to Set Performance Metrics for Your Service
Karena itu, Outcome-Based Acceptance Criteria sebenarnya dimulai sebelum development.
Saat business case disusun, team perlu mengetahui:
baseline-nya apa, target-nya apa, data source-nya apa, dan kapan measurement dianggap cukup representatif?
Jika pertanyaan tersebut baru muncul setelah go-live, organization berisiko tidak memiliki data untuk membuktikan apapun.
Dari Acceptance Criteria menuju Acceptance Chain
Traditional acceptance criteria sering berbentuk binary:
pass atau fail.
Business outcome tidak selalu dapat diperlakukan seperti itu karena value biasanya muncul melalui chain.
Misalnya application dibuat untuk menurunkan maintenance downtime.
Technology intervention pertama adalah digital inspection.
Namun digital inspection tidak secara langsung menurunkan downtime. Causal chain-nya dapat terlihat seperti:
Digital Inspection → Faster Issue Submission → Faster Work Order Creation → Faster Technician Response → Lower Repair Time → Reduced Downtime
Setiap titik memiliki evidence masing-masing.
Application dapat bekerja dengan sempurna, tetapi jika work order masih dibuat manual satu hari kemudian, downtime tidak berubah.
Outcome-Based Acceptance Criteria karena itu perlu menjaga causal traceability antara technology dan business impact.
Dalam working framework Crocodic:
Feature → Capability → Adoption → Process Change → Outcome → Business Impact
Kita tidak menuntut satu feature langsung menghasilkan profit.
Kita memastikan ada chain yang dapat diamati dari feature menuju perubahan yang memang relevan.
Jika chain tersebut putus, team tahu layer mana yang perlu diperiksa.
Definition of Adoption: Apakah Capability Benar-Benar Masuk ke Cara Kerja?
Software tidak menghasilkan business impact hanya karena tersedia.
User dapat tetap menggunakan spreadsheet.
Manager dapat tetap meminta report lewat chat.
Operations dapat tetap melewati workflow baru.
Department dapat menjalankan system lama secara parallel tanpa batas.
Karena itu, adoption perlu mempunyai criteria sendiri.
Namun adoption tidak hanya berarti login atau jumlah active user.
User dapat login setiap hari tetapi tetap menyelesaikan critical task melalui process lama.
Measurement yang lebih berguna adalah behavioral adoption: apakah activity yang menjadi target benar-benar berpindah menuju capability baru?
Jika system dibuat untuk digital inspection, pertanyaannya bukan hanya berapa inspector login, tetapi berapa proporsi inspection relevant yang dilakukan melalui process baru.
Jika automation dibuat untuk invoice matching, bukan hanya berapa kali feature terbuka, tetapi berapa transaction yang benar-benar masuk automated path.
Ini juga membuat Change Management menjadi internal dependency penting. Crocodic sudah memiliki pembahasan mengenai adopsi sistem, dan artikel tersebut memang berada pada inventory existing.
Tetapi adoption sendiri tetap bukan akhir.
User dapat menggunakan system dan outcome tetap tidak berubah.
Definition of Outcome: Apakah Operational Performance Benar-Benar Bergerak?
Outcome berada satu layer setelah adoption.
Jika feature digunakan, apakah process mengalami perubahan yang diharapkan?
Untuk approval automation, outcome dapat berupa waiting time yang lebih pendek.
Untuk integration, outcome dapat berupa reduction pada duplicate input dan reconciliation.
Untuk inspection application, outcome dapat berupa faster issue reporting.
Untuk AI assistant, outcome dapat berupa shorter resolution time atau reduced manual research.
GOV.UK menyarankan metric diturunkan dari purpose dan benefit service, kemudian hypothesis digunakan untuk menentukan apa yang perlu diukur. Mereka juga merekomendasikan continuous measurement agar organisasi dapat melihat trend dan membedakan perubahan yang disebabkan intervention dari variasi lain. GOV.UK
Konsep ini sangat sesuai untuk enterprise.
Outcome criteria tidak perlu seratus metric.
Justru terlalu banyak KPI membuat attribution semakin kabur.
Idealnya setiap intervention memiliki beberapa evidence yang sangat dekat dengan causal chain.
Misalnya objective-nya mengurangi processing cycle.
Metric utama: end-to-end cycle time.
Leading evidence: waiting time pada step yang diintervensi.
Adoption evidence: proportion process yang menggunakan capability baru.
Sekarang management dapat melihat bukan hanya hasil akhirnya, tetapi mengapa hasil tersebut terjadi atau tidak terjadi.
Definition of Value: Apakah Outcome Cukup Penting bagi Bisnis?
Tidak semua improvement otomatis menghasilkan business value yang material.
Bayangkan processing time turun dari delapan jam menjadi tujuh jam lima puluh menit. Outcome secara statistik mungkin membaik, tetapi apakah perubahan sepuluh menit benar-benar berarti bagi business process?
Sebaliknya, penurunan processing time kecil pada critical high-volume process dapat menghasilkan value besar.
Definition of Value karena itu perlu menerjemahkan process outcome menuju significance bagi organisasi.
Value dapat berupa:
reduced operational cost, protected margin, additional capacity, reduced downtime, avoided risk, improved customer conversion, shorter cash cycle, faster decision, atau strategic capability lain.
Tidak semuanya harus diubah menjadi rupiah dengan false precision.
Yang dibutuhkan adalah business significance.
PMI menekankan bahwa benefits realization menghubungkan organizational strategy dengan project deliverables dan success measurement, serta perlu berlanjut sampai benefit benar-benar realized dan sustained. Institute Manajemen Proyek
Itulah perbedaan outcome dengan value.
Outcome mengatakan:
“Processing time turun.”
Value mengatakan:
“Penurunan tersebut memungkinkan team memproses volume lebih besar tanpa penambahan resource yang sebanding.”
Crocodic Outcome-Based Acceptance Framework
Untuk menyederhanakan governance, Crocodic dapat menggunakan framework berikut:
| Layer | Pertanyaan Acceptance | Contoh Evidence |
| Done | Apakah capability bekerja sesuai quality requirement? | Functional, security, reliability, performance |
| Adoption | Apakah target user/process benar-benar menggunakannya? | Usage pada intended workflow |
| Outcome | Apakah process atau behavior yang ditargetkan berubah? | Cycle time, error, manual effort, response time |
| Value | Apakah perubahan tersebut menghasilkan benefit yang meaningful? | Capacity, cost, risk, revenue, margin, continuity |
Framework ini sengaja tidak membuat satu layer menggantikan yang lain.
Feature yang memiliki outcome tinggi tetapi kualitas buruk tetap problem.
Software yang high quality tetapi tidak diadopsi juga problem.
Adoption tinggi tanpa outcome juga problem.
Outcome meningkat tetapi tidak memiliki meaningful value dapat menjadi signal bahwa target awal kurang strategis.
Business-impact-oriented development membutuhkan keempatnya agar success tidak hanya dibaca dari satu angle.
Acceptance Criteria Harus Dibuat sebelum Development, Bukan setelah Project Bermasalah
Outcome criteria yang baru ditentukan setelah implementation berisiko menjadi moving goalpost.
Jika project terlihat sukses, organization memilih metric yang mendukung narrative tersebut.
Jika project bermasalah, stakeholder memilih metric lain.
Karena itu, Definition of Outcome dan Definition of Value sebaiknya dirancang bersama Value Hypothesis sebelum full development dimulai.
Artikel sebelumnya mengenai Value Hypothesis menggunakan format:
Jika [intervention] mengubah [root cause], maka [metric] seharusnya bergerak dari [baseline] menuju [target], karena [causal assumption].
Outcome acceptance adalah kelanjutan langsung dari hypothesis tersebut.
Value Hypothesis berkata:
“Kami percaya ini akan terjadi.”
Outcome Acceptance berkata:
“Inilah evidence yang menentukan apakah kepercayaan tersebut benar.”
Dengan demikian:
Hypothesis → Intervention → Measurement → Acceptance Decision
menjadi satu lifecycle.
Dan jika evidence tidak mendukung hypothesis, organization dapat memperbaiki intervention atau menghentikan additional investment.
Hindari Vanity Metrics
Ketika business outcome sulit diukur, organization mudah menggunakan metric yang tersedia.
Jumlah login naik.
Page views bertambah.
Notification terkirim jutaan kali.
AI assistant menerima ribuan prompt.
Dashboard diakses ratusan user.
Metric tersebut dapat berguna, tetapi belum tentu menunjukkan value.
Jika objective AI assistant adalah mengurangi time spent searching internal knowledge, jumlah prompt yang tinggi bahkan dapat memiliki beberapa interpretation. User mungkin menyukai system. Bisa juga mereka harus bertanya berkali-kali karena jawaban tidak cukup membantu.
Karena itu, metric perlu memiliki relationship terhadap intended outcome.
McKinsey menggambarkan product organization yang lebih mature sebagai team yang mengukur success melalui customer outcomes, melakukan rigorous tracking terhadap customer data, dan menggunakan evidence tersebut untuk continuous improvement. McKinsey & Company McKinsey — The Bottom-Line Benefit of the Product Operating Model
Business-impact-oriented metric bertanya:
“Apa yang menjadi lebih baik karena capability ini?”
Bukan hanya:
“Seberapa banyak capability ini digunakan?”
Technical KPI Tetap Penting—Tetapi Jangan Disamakan dengan Business Outcome
Availability 99,9%.
API latency di bawah threshold.
Defect rate rendah.
Deployment frequency meningkat.
Test coverage baik.
Semua metric tersebut penting.
Tanpa reliable system, business process tidak dapat bergantung padanya.
Namun technical KPI adalah enabler of value, bukan value itu sendiri.
Availability tinggi menjadi meaningful jika system memang mendukung process penting.
Performance improvement menghasilkan business impact jika latency sebelumnya menyebabkan user drop-off, slow transaction, atau productivity issue.
Security control menciptakan value melalui risk reduction.
Architecture improvement menghasilkan value melalui reduced change friction atau increased scalability.
Business-impact-oriented development bukan tentang menghapus technical metrics.
Justru kita perlu membuat hubungan:
Technical Health → Capability Reliability → Process Performance → Business Value
Dengan demikian engineering quality tetap dihargai tanpa membuat organisasi berhenti pada metric internal teknologi.
Tidak Semua Outcome Harus Muncul dalam Waktu yang Sama
Salah satu tantangan Outcome-Based Acceptance adalah waktu.
Ada outcome yang terlihat segera setelah release.
Automation dapat langsung menurunkan manual task.
Ada outcome yang membutuhkan beberapa minggu karena user perlu beradaptasi.
Ada pula strategic benefit yang baru muncul ketika volume meningkat atau capability lain dibangun di atas platform tersebut.
Karena itu, setiap outcome membutuhkan measurement window yang masuk akal.
Misalnya:
Day 1–7 dapat melihat technical stability dan initial adoption.
Week 2–4 dapat melihat behavioral adoption.
Month 2–3 dapat melihat process outcome.
Periode lebih panjang mungkin diperlukan untuk economic realization.
Urutan tersebut bukan universal. Yang penting organisasi menyadari bahwa different value layers mature at different speeds.
Jika measurement terlalu cepat, project yang sebenarnya valuable dapat dianggap gagal sebelum adoption stabil.
Jika terlalu lama, organization dapat terus menginvestasikan budget pada intervention yang sebenarnya sudah menunjukkan evidence lemah sejak awal.
Outcome Owner perlu menentukan kapan evidence sudah cukup untuk mengambil decision.
Outcome-Based Acceptance Bukan Cara Menjamin ROI secara Kontraktual
Pada custom enterprise software, client dapat tergoda meminta vendor menjamin business KPI tertentu.
Contohnya:
“Software harus meningkatkan sales 20%.”
“System harus menurunkan operational cost 30%.”
“AI harus meningkatkan productivity 50%.”
Target tersebut mungkin relevan sebagai business objective, tetapi tidak selalu tepat menjadi contractual software acceptance criterion.
Sales dipengaruhi price, competition, demand, marketing, distribution, sales performance, dan product fit.
Operational cost dipengaruhi staffing, policy, volume, adoption, serta process redesign.
Technology hanya satu intervention dalam system yang lebih luas.
Karena itu, Crocodic memisahkan:
Vendor Accountability terhadap Technology Contribution
dengan
Enterprise Accountability terhadap Business Outcome
Technology partner tetap harus menjelaskan contribution hypothesis, membangun instrumentation, memberikan capability yang reliable, dan memastikan solution mendukung intended process.
Tetapi business outcome tetap memiliki shared dependencies.
Ini merupakan kelanjutan dari framework Outcome Ownership yang sudah kita bahas sebelumnya.
Business impact harus memiliki owner.
Tetapi ownership harus mengikuti control boundary yang realistis.
Jika Software Done tetapi Outcome Tidak Bergerak, Apa yang Harus Dilakukan?
Ini adalah momen di mana Outcome-Based Acceptance memberikan value terbesar.
Jangan langsung menambah feature.
Diagnosis causal chain lebih dahulu.
Jika adoption rendah, periksa onboarding, usability, process policy, training, incentive, atau coexistence dengan process lama.
Jika adoption tinggi tetapi operational outcome tidak bergerak, periksa root cause dan Value Hypothesis.
Jika operational outcome bergerak tetapi business value tidak muncul, periksa apakah magnitude improvement cukup atau downstream process masih menjadi constraint.
Jika outcome tercapai tetapi biaya maintenance terlalu tinggi, economic case perlu dilihat kembali.
Dengan kata lain:
No Outcome → Diagnose the Chain
bukan
No Outcome → Build More Features
Ini penting karena feature-driven organization cenderung merespons weak outcome dengan menambah backlog.
Padahal problem dapat berada di luar software.
Outcome Acceptance juga Menentukan Kapan Development Boleh Berhenti
Framework ini tidak hanya berguna ketika project gagal.
Ia juga membantu organization berhenti ketika project berhasil.
Bayangkan roadmap awal memiliki sepuluh feature karena team memperkirakan semuanya dibutuhkan untuk menurunkan processing time.
Setelah lima feature pertama dirilis, adoption tinggi dan business KPI sudah mencapai target.
Apakah lima feature berikutnya otomatis masih harus dibangun?
Tidak.
Jika target outcome telah tercapai, remaining scope perlu dievaluasi kembali melalui Marginal Value of Features.
Sebagian tetap perlu dibangun untuk security, completeness, regulatory requirement, atau future capability.
Tetapi feature lain mungkin tidak lagi memiliki business urgency.
Outcome Acceptance membuat organization memiliki evidence untuk mengatakan:
“Investment ini sudah mencapai objective. Tambahan development sekarang membutuhkan business case baru.”
Ini membuat development lebih economically disciplined.
Post-Go-Live Review Harus Membahas Value, Bukan Hanya Bug
Post-implementation review sering berfokus pada operational issues.
Berapa bug ditemukan?
Apakah server stabil?
Apakah support ticket turun?
Apakah migration selesai?
Pertanyaan tersebut penting, tetapi review seharusnya juga kembali kepada original business case.
Apakah baseline berubah?
Apakah Value Hypothesis terbukti?
Apakah intended behavior muncul?
Apakah outcome berada di trajectory yang benar?
Benefit apa yang belum terealisasi?
Apakah intervention perlu disesuaikan?
PMI Benefits Realization Management secara eksplisit memperpanjang lifecycle benefit setelah project execution sampai benefit sustained oleh business. Institute Manajemen Proyek
Post-go-live dengan demikian bukan hanya stabilisation period.
Ia merupakan value validation period.
AI Membuat Outcome-Based Acceptance Semakin Penting
Pada deterministic software, acceptance relatif mudah. Input tertentu menghasilkan output yang sudah ditentukan.
AI menambah uncertainty.
Model dapat menghasilkan output yang probabilistic. Accuracy dapat berubah antaruse case. User behavior dapat berubah karena recommendation. Human review mungkin tetap diperlukan.
Karena itu, menyatakan AI system berhasil hanya karena model deployed atau API bekerja menjadi semakin tidak memadai.
Misalnya AI digunakan untuk document classification.
Definition of Done dapat mencakup integration, security, logging, latency, dan quality threshold.
Definition of Adoption melihat berapa besar eligible document benar-benar masuk AI workflow.
Definition of Outcome melihat apakah manual classification berkurang tanpa unacceptable increase pada correction.
Definition of Value melihat apakah operational capacity atau turnaround time benar-benar membaik.
Crocodic sudah memiliki AI Value Realization yang membahas pengukuran dampak AI, dan artikel tersebut terdapat dalam inventory saat ini. Outcome-Based Acceptance memperluas principle yang sama untuk seluruh enterprise software, bukan hanya AI.
Crocodic Perspective: Software Can Be Done Before Its Value Is Proven
Dalam perspective Crocodic, salah satu sumber feature-driven development adalah penyamaan antara delivery success dan business success.
Ketika feature selesai, progress dianggap tercapai.
Ketika semua feature selesai, project dianggap sukses.
Namun business-impact-oriented development membutuhkan dua definition yang berbeda:
Definition of Done: Apakah kita membangun capability dengan benar?
Definition of Value: Apakah capability tersebut menghasilkan perubahan yang layak bagi bisnis?
Di antara keduanya terdapat:
Definition of Adoption dan Definition of Outcome.
Sehingga framework lengkapnya:
Done → Adoption → Outcome → Value
atau secara causal:
Technology Intervention → Usage/Behavior Change → Process Change → Business Impact
Scrum Guide memberikan discipline yang kuat mengenai shared understanding terhadap Increment yang benar-benar Done. GOV.UK Service Manual mendorong measurement dirancang sejak awal berdasarkan purpose, benefits, hypothesis, baseline, dan target. PMI memperpanjang perhatian project sampai benefit realized dan sustained. McKinsey juga menekankan accountability terhadap business outcomes dan data-driven measurement dalam mature product operating model. Panduan Scrum
Dalam Crocodic, prinsip tersebut dapat dirangkum menjadi:
Software dapat selesai sebelum value-nya terbukti. Karena itu, go-live seharusnya menutup fase delivery—bukan menutup pertanyaan tentang business impact.
Kesimpulan
Acceptance criteria tetap menjadi bagian fundamental software engineering. Enterprise membutuhkan kejelasan mengenai kapan feature berfungsi, kapan quality requirement terpenuhi, dan kapan software cukup reliable untuk digunakan.
Namun jika technology investment dibuat untuk mengubah kondisi bisnis, technical acceptance tidak cukup untuk mendefinisikan seluruh keberhasilan.
Crocodic melihat empat layer:
Definition of Done → Definition of Adoption → Definition of Outcome → Definition of Value
Definition of Done memastikan capability bekerja.
Definition of Adoption memastikan capability benar-benar masuk ke process.
Definition of Outcome menunjukkan process atau behavior berubah.
Definition of Value menunjukkan perubahan tersebut cukup meaningful bagi bisnis.
Pendekatan ini juga menjaga accountability tetap realistis. Developer dan technology partner tidak perlu menjamin seluruh KPI perusahaan. Sebaliknya, mereka perlu memastikan technology contribution jelas, measurable, reliable, dan dapat ditelusuri menuju intended outcome. Business owner tetap memegang process, adoption, dan broader business decision yang berada dalam authority-nya.
Outcome-Based Acceptance Criteria pada akhirnya mengubah satu pertanyaan fundamental.
Traditional development bertanya:
“Apakah software sudah selesai?”
Business-impact-oriented development menambahkan:
“Jika sudah selesai, apakah sesuatu yang bernilai bagi bisnis juga mulai berubah?”
Karena software yang berhasil go-live adalah delivered capability.
Software yang mengubah operating performance adalah realized outcome.
Dan hanya ketika perubahan tersebut benar-benar berarti bagi bisnis, technology investment mulai membuktikan value-nya.
Discussion