BA Playbook
The Business Says It's a Defect. Tech Says It's Expected Behaviour.
Both sides may be telling the truth. Here's how to find out which.
Surya · August 14, 2026 · 4 min read · 10 practices
For Business Analysts stuck between "this is a defect" and "this is expected behaviour", BAs who want a repeatable way to classify a disputed system behaviour, QA and developers deciding whether something is a bug or a spec and Delivery leads who want disagreements resolved with evidence, not opinion.
A claims user tries to backdate an insurance claim by ten days. The system rejects it. Business says: "Defect. We need to backdate claims." Technology says: "Expected behaviour. The system rejects dates older than seven days." Now the BA is in the middle. Is it a defect? Expected behaviour? Or did everyone build a different expectation? The BA's job is not to pick a side. It is to answer a better question: what should the system actually do? Maybe the requirement really does say seven days. Maybe the business process changed after it was written. Maybe acceptance criteria never covered this scenario. Maybe seven days is a configuration nobody explained. So don't begin with "who is right?" Begin with "what was intended, what was built, and what does the business need now?" That question breaks into eight steps: listen for the business pain, recreate the exact scenario, check the requirement, check acceptance criteria, compare all three views side by side, classify what kind of issue this actually is, ask whether the business need has changed since, then decide and document so the same argument doesn't come back next sprint.
01Step 01
LISTEN — Understand the business pain
"System won't allow backdating" describes behaviour. "Operations cannot process legitimate late claims" describes the business problem.
Step 01
LISTEN — Understand the business pain
"System won't allow backdating" describes behaviour. "Operations cannot process legitimate late claims" describes the business problem.
At a glance
- What were you trying to achieve?
- What happened instead?
- What impact does it create?
- Is there a workaround?
- How often does it happen?
- Who is affected?
Why it helps
Opening Jira before understanding the business problem means you're about to investigate the wrong thing precisely.
02Step 02
RECREATE — See the behaviour yourself
Don't debate a defect you cannot describe precisely.
Step 02
RECREATE — See the behaviour yourself
Don't debate a defect you cannot describe precisely.
Get the exact scenario. Claim date: 1 August. Entry date: 11 August. Business expects: claim accepted. Actual: "Claim date cannot be more than 7 days in the past." Now you have something testable.
At a glance
- Capture: user
- data
- steps
- expected
- actual
Why it helps
A precise, reproducible scenario is what turns a hallway argument into an investigation everyone can check.
03Step 03
REQUIREMENT — What was actually asked for?
Technology may have built the requirement exactly as written — but that's not the end of the investigation.
Step 03
REQUIREMENT — What was actually asked for?
Technology may have built the requirement exactly as written — but that's not the end of the investigation.
Suppose the requirement says claims may be backdated by a maximum of seven calendar days. Technology may have implemented it correctly, so the current behaviour may not be a software defect. But the requirement itself may still be incomplete, outdated, or no longer fit the business need.
At a glance
- requirement
- user story
- business rules
- process flow
- design
- decision log
- change history
- relevant policy
Why it helps
Checking the requirement before arguing about behaviour stops both sides from debating from memory instead of evidence.
04Step 04
ACCEPTANCE — What result did we agree to?
Requirements describe intent. Acceptance criteria make behaviour testable.
Step 04
ACCEPTANCE — What result did we agree to?
Requirements describe intent. Acceptance criteria make behaviour testable.
Compare
Clear acceptance criteria
"Given a claim date older than seven days, when the user submits, then the system prevents submission." — the behaviour is clearly intentional.
Ambiguous acceptance criteria
"Claims can be created with a past date." Seven days? Thirty? Any past date? That's not a coding defect — it's a requirement gap.
At a glance
- boundaries
- exceptions
- negative cases
- roles
- error messages
- alternate flows
Why it helps
The AC tells you whether the disputed scenario was ever actually decided, or just assumed.
05Step 05
COMPARE — Business need vs requirement vs behaviour
Put the three views side by side and the conversation becomes useful.
Step 05
COMPARE — Business need vs requirement vs behaviour
Put the three views side by side and the conversation becomes useful.
The system matches the requirement. But the requirement may not satisfy the current business need. That's different from saying "Tech is right." A better conclusion: the system is behaving as specified, but the current rule doesn't support the business scenario.
At a glance
- Business need — Valid late claims must be processed.
- Requirement — Backdating limited to 7 days.
- System — Rejects anything older than 7 days.
Why it helps
Naming which of the three views is out of step with the others tells you what kind of problem you're actually solving.
06Step 06
CLASSIFY — What kind of issue is it?
The same disagreement can resolve to four very different classifications.
Step 06
CLASSIFY — What kind of issue is it?
The same disagreement can resolve to four very different classifications.
At a glance
- Defect — behaviour differs from the agreed requirement/AC (requirement allows 7 days, system rejects 5).
- Expected behaviour — behaviour matches the agreed rule (requirement allows 7 days, system rejects 10) — though that doesn't mean nothing should change; it may now be a change request instead of a defect fix.
- Requirement gap — the scenario was never clearly defined (requirement says "claims can be backdated," no limit, no exception, no boundary) — the team needs a decision.
- Configuration or data issue — the logic is correct but the setup isn't (requirement says 7 days, configuration says 3) — the symptom looks like a defect, but the root cause is elsewhere.
Why it helps
Each classification points to a different next action — fix code, update a requirement, get a decision, or correct a config. Getting this wrong sends the fix to the wrong team.
07Step 07
CURRENT NEED — Has something changed?
A system can correctly implement yesterday's requirement and still be wrong for today's business.
Step 07
CURRENT NEED — Has something changed?
A system can correctly implement yesterday's requirement and still be wrong for today's business.
At a glance
- Maybe regulation introduced an exception.
- Maybe Operations changed its process.
- Maybe a new product needs 30-day backdating.
- Maybe the original assumption was wrong.
Why it helps
Don't force today's need into yesterday's documentation — naming the change explicitly is what turns "expected behaviour" into a legitimate change request.
08Step 08
DECIDE & DOCUMENT — Close the ambiguity
By the end, capture enough that the same argument can't return next sprint.
Step 08
DECIDE & DOCUMENT — Close the ambiguity
By the end, capture enough that the same argument can't return next sprint.
At a glance
- Observed behaviour — what does the system do?
- Expected behaviour — what should it do now?
- Evidence — which requirement, AC, rule, or policy supports the conclusion?
- Classification — defect / expected behaviour / requirement gap / configuration-data issue / change.
- Decision — fix, change, configure, clarify, or accept.
- Owner — who decides or delivers the next action?
Why it helps
Then update the relevant requirement, AC, decision log, configuration, or defect — the decision only sticks if the documentation changes with it.
09Step 09
A second example: same disagreement, different answer
Evidence decides — not which side sounds more confident.
Step 09
A second example: same disagreement, different answer
Evidence decides — not which side sounds more confident.
Check the requirement: "Orders may be cancelled before dispatch." PACKED is before DISPATCHED. Technology's rule is stricter than the agreed requirement. That's a defect — the opposite conclusion from the backdated-claims example, reached by the same method.
Compare
Business says
"Customers can't cancel orders after packing. That's a defect."
Technology says
"Expected. Cancellation is disabled once status = PACKED."
Why it helps
The method doesn't pre-decide who's right. It just makes sure the requirement, not the louder voice, settles the question.
10Step 10
The BA trap: becoming the referee
Don't relay opinions. Bring evidence.
Step 10
The BA trap: becoming the referee
Don't relay opinions. Bring evidence.
Compare
Relaying opinions
"Business says this is wrong." / "Tech says this is exactly what you asked for."
Bringing evidence
"The requirement allows cancellation until dispatch. Current behaviour blocks it at packing. That differs from the agreed rule."
Why it helps
A BA doesn't need to prove someone made a mistake — the goal is to remove ambiguity so everyone knows what to build and test.
Pro tip — Or: "The seven-day limit matches the approved requirement. The business now needs a 30-day exception, so this is a requirement change." Either way, the conversation moves forward instead of restarting.
"Defect" doesn't mean the business dislikes the outcome.
A good BA makes expected behaviour clear enough that the argument disappears.
Sometimes the system is wrong. Sometimes the expectation is wrong. Sometimes the requirement is incomplete. Sometimes the business need changed. The BA's job is to separate those possibilities — don't take sides, compare intent, evidence, and outcome.
Take this with you
Defect vs Expected Behaviour Decision Sheet
DEFECT vs EXPECTED BEHAVIOUR — DECISION SHEET Classify with evidence, not opinion. FAST EVIDENCE TABLE Business needs: ______________________________ Requirement / AC says: ______________________________ System actually does: ______________________________ Classification: Defect / Expected / Gap / Config-Data / Change Decision + owner: ______________________________ BEFORE YOU CLOSE IT [ ] Scenario is precise. [ ] Requirement/AC evidence checked. [ ] Business outcome understood. [ ] Classification is evidence-based. [ ] Decision owner is clear. [ ] Relevant story/AC/defect/config updated. GOLDEN RULE Don't take sides. Compare intent, evidence and outcome. The goal is not to win the argument. It is to make expected behaviour unambiguous.
Get new playbooks first.