Part 007 — Good Stories, Bad Stories, INVEST, and Business Rule Capture

Positioning

User story bukan requirement document mini.

User story adalah alat untuk membangun shared understanding tentang:

• siapa yang membutuhkan perubahan;
• behavior apa yang diharapkan;
• mengapa behavior itu penting;
• rule apa yang mengaturnya;
• apa yang masih belum diketahui;
• dan bagaimana tim dapat memecahnya menjadi increment yang dapat diuji.

Masalah utama bukan apakah template As a / I want / So that digunakan. Masalah utamanya adalah apakah story menghasilkan percakapan yang cukup untuk mengurangi ambiguity dan delivery risk.

Core thesis: story yang baik bukan story yang terlihat rapi di board. Story yang baik adalah story yang membuat product, engineering, QA, dan stakeholder memahami behavior, boundary, dan evidence yang sama.

1. User Story sebagai Conversation Boundary

User story sebaiknya dipahami melalui tiga elemen klasik:

Card
Conversation
Confirmation

Card

Representasi ringkas work item.

Conversation

Diskusi untuk membangun shared understanding.

Confirmation

Acceptance criteria dan evidence bahwa behavior telah terpenuhi.

Jika organisasi hanya memiliki card, maka story berubah menjadi placeholder administratif.

1.1 Story bukan specification lengkap

Story tidak perlu memuat setiap detail.

Tetapi story harus cukup kuat untuk:

• memicu pertanyaan penting;
• menampilkan value;
• mengidentifikasi rule;
• dan menentukan kapan detail tambahan dibutuhkan.

1.2 Story bukan implementation order

Lemah:

Add endpoint /quote/approve.

Lebih baik:

As a quote approver, I can approve a quote that exceeds the configured discount threshold so that exception sales can proceed under controlled authorization.

Story kedua memberi ruang untuk menemukan:

• threshold source;
• approver identity;
• state transition;
• audit;
• dan failure condition.

2. Anatomy of a Useful Story

2.1 Actor

Actor bukan selalu user manusia.

Actor dapat berupa:

• quote manager;
• approver;
• customer administrator;
• support analyst;
• downstream ordering system;
• operations engineer;
• atau compliance reviewer.

Namun actor seperti system atau developer sering terlalu generik.

2.2 Capability

Capability menjelaskan behavior yang dapat dilakukan atau dialami.

Contoh:

• submit quote for approval;
• inspect failed order;
• configure discount threshold;
• retry eligible transition;
• view audit evidence.

2.3 Value

Value menjelaskan alasan capability penting.

Contoh:

• reduce manual escalation;
• prevent unauthorized discount;
• improve support diagnosis;
• allow safe recovery;
• maintain compliance evidence.

2.4 Context

Story sering membutuhkan tambahan:

• business background;
• affected workflow;
• current limitation;
• customer evidence;
• dan known constraints.

2.5 Boundary

Story harus cukup jelas mengenai apa yang tidak termasuk.

Contoh:

In scope:
- One approval level
- One discount threshold
- Existing approver group

Out of scope:
- Delegation
- Multi-stage approval
- Threshold by product family

3. Good Story versus Bad Story

3.1 Good story characteristics

Good story:

• outcome-oriented;
• testable;
• small enough;
• connected to a user or business behavior;
• explicit about ambiguity;
• and open to implementation discussion.

3.2 Bad story patterns

Technical command disguised as story

As a developer, I want to create a new table.

Masalah:

• actor tidak menerima product value;
• solution sudah dipilih;
• behavior tidak terlihat.

Feature label only

Implement approval.

Masalah:

• scope tidak jelas;
• rule tidak jelas;
• actor tidak jelas;
• evidence tidak jelas.

Giant workflow

As a sales user, I want complete quote approval.

Masalah:

• terlalu luas;
• banyak state;
• banyak dependency;
• sulit diuji sebagai satu increment.

UI-only story

Add approval button.

Masalah:

• behavior backend;
• authorization;
• state;
• audit;
• dan error tidak terlihat.

Requirement dump

Story berisi puluhan rule tanpa coherent behavior.

Masalah:

• sulit di-slice;
• discussion menjadi review dokumen;
• dan dependency tersembunyi.

4. INVEST

INVEST adalah heuristic untuk menilai story.

4.1 Independent

Story sebaiknya cukup independen untuk diurutkan dan diselesaikan.

Bukan berarti tidak boleh memiliki dependency.

Pertanyaannya:

• apakah dependency nyata;
• dapatkah interface distabilkan;
• dapatkah sequencing diubah;
• dan apakah story masih memiliki value sendiri.

4.2 Negotiable

Story bukan fixed contract detail.

Negotiable berarti:

• solution dapat didiskusikan;
• scope dapat disesuaikan;
• dan trade-off dapat dibuat.

Bukan berarti requirement boleh kabur selamanya.

4.3 Valuable

Story harus menghasilkan value atau learning.

Value dapat berupa:

• user capability;
• risk reduction;
• operational improvement;
• atau validated assumption.

4.4 Estimable

Team memiliki cukup informasi untuk memberikan relative forecast.

Jika tidak estimable:

• mungkin terlalu besar;
• ambiguity tinggi;
• dependency unknown;
• atau membutuhkan spike.

4.5 Small

Story cukup kecil untuk diselesaikan dalam Sprint dengan flow sehat.

Small bukan hanya jumlah code.

Pertimbangkan:

• integration;
• review;
• test;
• environment;
• rollout;
• dan operational evidence.

4.6 Testable

Behavior dan expected result dapat diverifikasi.

Jika story tidak testable, kemungkinan:

• value tidak jelas;
• rule tidak eksplisit;
• atau output terlalu abstrak.

4.7 INVEST bukan checklist mekanis

Sebuah story tidak harus “sempurna” pada semua aspek.

Gunakan INVEST untuk menemukan percakapan berikutnya.

5. Story Quality Model

Gunakan enam dimensi.

5.1 Story health signal

High intent + low detail
= needs refinement

High detail + low intent
= requirement dump

High intent + sufficient behavior + explicit uncertainty
= healthy story

6. Business Rule Capture

Business rule adalah constraint atau decision logic yang mengatur behavior.

Contoh:

• discount above 20% requires approval;
• expired quote cannot be submitted;
• approved quote edited in material field requires re-approval;
• only assigned approver group may approve;
• order cannot be retried after irreversible downstream completion.

6.1 Rule categories

Eligibility rule

Menentukan apakah actor atau entity memenuhi syarat.

Calculation rule

Menentukan hasil numerik.

Validation rule

Menentukan data valid atau tidak.

Authorization rule

Menentukan siapa boleh melakukan action.

State transition rule

Menentukan perpindahan state.

Temporal rule

Menentukan behavior berdasarkan waktu.

Compatibility rule

Menentukan behavior lintas version atau consumer.

Exception rule

Menentukan kasus penyimpangan.

6.2 Rule source

Business rule dapat berasal dari:

• product policy;
• customer contract;
• regulation;
• legacy behavior;
• support workaround;
• subject-matter expert;
• atau implicit code.

Source harus dicatat bila consequence tinggi.

7. Business Rule Representation

7.1 Decision table

Decision table membantu menemukan:

• overlap;
• missing combination;
• dan precedence.

7.2 State transition table

7.3 Rule statement

Given a quote is approved
When a material pricing field changes
Then the quote must require approval again

7.4 Rule hierarchy

Be careful with:

• global rule;
• tenant override;
• product-family rule;
• customer-specific exception;
• and temporary policy.

Rule precedence harus eksplisit.

8. Domain Language

Story harus menggunakan ubiquitous language yang konsisten.

Dalam domain Quote & Order, istilah yang mirip bisa berbeda:

• submit quote;
• approve quote;
• accept quote;
• confirm quote;
• convert quote to order.

Jika tim menggunakan istilah berbeda, bug semantik mudah muncul.

8.1 Glossary discipline

Catat:

Term:
Definition:
State implications:
Related terms:
Owner/source:

8.2 Language smell

• satu istilah memiliki banyak arti;
• UI label berbeda dari API/state;
• customer language berbeda dari internal language;
• dan ticket menggunakan terminology teknis untuk behavior bisnis.

9. Story Slicing Signals

Part 012 membahas slicing mendalam. Pada tahap story quality, lihat signal berikut.

Story terlalu besar jika:

• memiliki banyak actor;
• banyak state transition;
• banyak integration boundary;
• banyak independent acceptance group;
• banyak rollout stage;
• atau estimasi sangat divergen.

Story dapat di-slice berdasarkan:

• workflow step;
• rule variation;
• actor;
• data type;
• integration;
• risk;
• dan rollout.

Avoid fake slice

Lemah:

• database story;
• backend story;
• frontend story;
• QA story.

Itu horizontal handoff, bukan product slice.

10. Story versus Use Case

Use case dapat lebih tepat untuk workflow kompleks.

User story

Ringkas dan cocok untuk backlog item.

Use case

Lebih detail:

• precondition;
• primary flow;
• alternate flow;
• exception;
• postcondition.

Untuk complex enterprise workflow, story dapat menunjuk ke use case atau state model.

Jangan paksa semua detail masuk title dan description.

11. Story versus Job Story

Job story format:

When <situation>
I want to <motivation>
So I can <expected outcome>

Berguna ketika:

• context lebih penting dari persona;
• actor title terlalu generik;
• behavior dipicu kondisi tertentu.

Contoh:

When an order remains in processing beyond the expected duration, I want to see the blocking transition and retry eligibility so I can resolve the issue without database access.

12. Story versus Technical Task

Gunakan user story ketika behavior dan actor adalah pusat.

Gunakan technical task ketika:

• implementation work internal;
• no direct user behavior;
• but clear engineering outcome.

Jangan memalsukan actor.

Technical task tetap harus terhubung ke outcome.

13. Story versus Spike

Gunakan spike ketika pertanyaan utama adalah uncertainty.

Contoh:

Story:

Customer admin can configure approval threshold.

Spike:

Determine whether threshold configuration can be added without breaking existing tenant-specific rule resolution.

Spike bukan story implementation kecil.

14. Story Refinement Conversation

Gunakan sequence:

1. What problem are we solving?
2. Who experiences it?
3. What behavior must change?
4. What rules apply?
5. What examples prove the rule?
6. What edge conditions matter?
7. What is out of scope?
8. What dependency exists?
9. What is the smallest useful slice?
10. What evidence means Done?

14.1 Three Amigos

Kolaborasi product/business, engineering, dan QA sering disebut Three Amigos.

Tujuannya:

• align intent;
• discover examples;
• identify risk;
• dan avoid handoff.

Bukan berarti hanya tiga orang atau harus menjadi meeting formal.

15. Senior Engineer Challenge Patterns

Senior engineer perlu challenge story lemah tanpa mendominasi.

15.1 Challenge intent

Outcome apa yang ingin berubah setelah capability ini tersedia?

15.2 Challenge actor

Siapa yang mengalami problem ini dan siapa yang memiliki authorization?

15.3 Challenge state

State awal dan akhir apa? Apa transisi invalid?

15.4 Challenge integration

Consumer mana yang bergantung pada behavior ini?

15.5 Challenge compatibility

Bagaimana existing tenant atau API consumer diperlakukan?

15.6 Challenge operability

Bagaimana support mengetahui proses gagal?

15.7 Challenge scope

Variation mana yang dapat ditunda tanpa membuat slice tidak berguna?

16. Failure Modes

16.1 Story template worship

Tim fokus melengkapi sentence, bukan memahami problem.

16.2 Acceptance after implementation

Rule ditemukan QA setelah coding selesai.

16.3 Solution anchoring

Story sudah menentukan solution sebelum options dibahas.

16.4 Product-context loss

Story diturunkan dari epic tanpa alasan dan customer context.

16.5 Hidden non-functional behavior

Performance, security, observability, dan compatibility tidak dibahas.

16.6 Persona theater

Persona dibuat tetapi tidak memengaruhi behavior.

16.7 Story factory

Success diukur dari jumlah story yang siap.

17. Worked Example: Quote Reapproval

Weak story

Add reapproval logic.

Better story

As a quote approver, I need material changes to an approved quote to trigger reapproval so that the final commercial commitment remains authorized.

Key rules

• pricing changes require reapproval;
• note-only changes do not;
• reapproval clears previous approver decision;
• audit history remains;
• downstream submission must be blocked until reapproved.

Questions

• apa yang dianggap material;
• bagaimana bundled pricing;
• apakah customer acceptance juga invalidated;
• bagaimana existing integrations melihat state baru;
• dan bagaimana migration quote lama.

Slice

First slice:

• one material field category;
• existing approval route;
• no delegation;
• audit event;
• feature flag.

18. Story Review Heuristic

Sebelum story dianggap refined, jawab:

Problem:
Actor:
Behavior:
Value:
Rules:
Examples:
Boundary:
Unknown:
Dependency:
Evidence:

Jika beberapa field kosong, belum tentu story gagal.

Tetapi gap harus disadari.

19. Story Documentation Pattern

## Context

Current behavior and problem.

## User / Actor

Who is affected.

## Desired Behavior

What changes.

## Business Rules

Rules and precedence.

## Examples

Representative scenarios.

## Scope

In scope / out of scope.

## Risks and Dependencies

Known uncertainty.

## Acceptance Criteria

Testable confirmation.

Gunakan sesuai kebutuhan. Jangan jadikan semua section mandatory jika tidak membantu.

20. Process Smells

• story title tidak menjelaskan behavior;
• actor selalu “user”;
• value selalu “improve experience”;
• acceptance criteria copied;
• rule hanya ada di chat;
• ambiguity baru muncul saat QA;
• banyak story reopened;
• refinement membahas implementation terlalu cepat;
• dan story ready tanpa product representative.

21. Senior Engineer Operating Model

Before refinement

• baca context;
• cari domain rule;
• identifikasi state;
• dan tandai dependency.

During refinement

• ajukan example;
• pisahkan fact dan assumption;
• challenge scope;
• dan bantu QA menemukan negative path.

After refinement

• dokumentasikan technical risk;
• jangan mengubah behavior diam-diam saat coding;
• dan update story jika learning berubah.

During implementation

Jika behavior ambiguity muncul:

• pause;
• expose question;
• involve decision owner;
• record answer.

Jangan memilih business behavior sendiri karena “lebih masuk akal”.

22. Internal Verification Checklist

Story convention

• Apakah tim memakai user story template?
• Apa field wajib?
• Apakah story digunakan untuk semua work type?
• Apa contoh story yang dianggap baik?
• Apa anti-pattern historis?

Domain rules

• Di mana business rules disimpan?
• Siapa source of truth?
• Apakah ada domain glossary?
• Bagaimana tenant/customer variation dicatat?
• Apakah legacy behavior dianggap contract?

Refinement

• Siapa hadir?
• Apakah QA dan designer terlibat?
• Kapan architecture atau support dilibatkan?
• Apakah example mapping digunakan?
• Apa readiness expectation?

Traceability

• Apakah story terhubung ke epic/feature?
• Apakah customer evidence tersedia?
• Apakah design/state model dilink?
• Apakah decision record digunakan?

Quality

• Berapa banyak defect berasal dari misunderstood rule?
• Apakah acceptance berubah setelah implementation?
• Apakah reopened story umum?
• Apakah hidden scope sering muncul?

23. Practical Exercises

Exercise 1 — Rewrite bad story

Ubah:

Add order retry button.

Menjadi story yang menjelaskan:

• actor;
• trigger;
• eligibility;
• value;
• dan safety.

Exercise 2 — INVEST audit

Pilih lima story dan nilai:

Catat conversation yang dibutuhkan.

Exercise 3 — Business rule extraction

Ambil requirement prose.

Ekstrak:

• eligibility;
• validation;
• authorization;
• state transition;
• exception.

Exercise 4 — Domain glossary

Pilih lima istilah yang sering ambigu.

Definisikan dan validasi dengan product/domain expert.

Exercise 5 — Story boundary

Untuk satu story besar, tulis:

• in scope;
• out of scope;
• follow-up;
• dan assumption.

24. Part Completion Checklist

Anda selesai jika mampu:

• menjelaskan story sebagai card, conversation, confirmation;
• menilai story dengan INVEST;
• membedakan good dan bad story;
• menangkap business rule;
• menggunakan decision table atau state transition;
• membedakan story, task, spike, dan use case;
• challenge ambiguity secara konstruktif;
• dan menjaga product decision tetap pada owner yang tepat.

25. Key Takeaways

1. Template bukan story quality.
2. Story adalah alat shared understanding.
3. Business rule harus eksplisit dan dapat diuji.
4. INVEST adalah heuristic conversation.
5. Domain language yang konsisten mengurangi semantic defect.
6. Story terlalu besar biasanya membawa banyak independent uncertainty.
7. Tidak semua work perlu user-story format.
8. Senior engineer harus challenge behavior, risk, dan boundary.
9. Ambiguity tidak boleh diselesaikan diam-diam saat coding.
10. Story convention internal harus diverifikasi.

26. References

Conceptual baseline:

• Agile Manifesto and principles.
• User story practices, including Card–Conversation–Confirmation and INVEST.
• General domain modeling and example-driven refinement practices.

These concepts do not describe internal CSG processes.