Why a Story Keeps Carrying Over — A BA Diagnostic Guide

Sprint 1: carried over.

Sprint 2: carried over.

Sprint 3: carried over.

Monday morning.

Sprint 4.

And there it is again.

ABC-142.

Same title.

Same story points.

Same slightly uncomfortable feeling when somebody asks:

“What’s left on this one?”

Someone says:

“It’s almost done.”

Which is interesting.

Because it was almost done three weeks ago too.

At this point, I wouldn’t ask:

“How do we finish this story?”

I’d ask:

“Why has this story survived four sprints?”

Because a story that keeps carrying over is usually telling you something.

The mistake is treating the carry-over itself as the problem.

Let’s open the ticket.

First, stop calling it “almost done”

ABC-142 says:

Status: In Progress

The latest comment says:

“Development almost complete. Pending final validation.”

Sounds reasonable.

But “almost done” is not particularly useful.

So ask:

What exactly is unfinished?

Not:

“How much is left?”

Not:

“What percentage is complete?”

Actually name the remaining thing.

We ask the developer.

Turns out:

UI is finished.
Backend changes are finished.
API integration is finished.
Unit testing is finished.

So development isn’t really the problem.

QA is waiting.

Okay.

Now we have somewhere to look.

The story is not blocked by everything

This is a useful distinction.

A story can look stuck as one big object.

But usually only one part is actually stuck.

ABC-142 has been sitting in “In Progress” for weeks.

That makes it feel like the whole story is unfinished.

It isn’t.

Most of it is done.

The remaining issue is:

QA cannot complete one test scenario.

Much better.

Now ask:

Why?

QA says the expected behaviour is unclear

The scenario is simple.

An upstream service normally returns customer risk data.

But sometimes the service returns no record.

QA asks:

“What should happen when no risk record is returned?”

The acceptance criteria say:

System should handle the response appropriately.

There’s that word.

Appropriately.

Development interpreted that as:

Continue processing.

QA interpreted it as:

Stop processing and show an error.

The business hasn’t confirmed either.

So now we know something important.

ABC-142 is not really waiting for QA.

QA is waiting for a requirement.

So we check the requirement

Maybe the answer is already somewhere.

We look through the ticket.

Description.

Nothing.

Acceptance criteria.

Nothing.

Linked Confluence page.

Nothing.

Then we reach the comments.

Comment #38:

“Need business confirmation on expected behaviour when no risk record is returned.”

Posted 13 days ago.

No answer.

There it is.

Four sprints of carry-over.

And the actual blocker is one unanswered question sitting inside a Jira comment.

The story wasn’t blocked by development.

It wasn’t really blocked by QA either.

It was blocked by a decision nobody had made visible.

This is why carry-over is useful information

It’s tempting to treat carry-over as a planning problem.

Maybe estimation was bad.

Maybe the team took too much work.

Maybe velocity is falling.

Sometimes that is exactly what happened.

But repeated carry-over deserves a different question.

Not:

Why are we slow?

Ask:

What kind of unfinished work keeps surviving the sprint boundary?

Because “unfinished” can mean very different things.

There are at least six kinds of unfinished

When I see a story repeatedly carrying over, I try to classify the blocker.

1. Technical unfinished

There is genuinely more implementation work.

Code is incomplete.

Integration is incomplete.

A technical problem has not been solved.

Straightforward.

2. Requirement unfinished

The team does not actually know what the system should do.

Maybe:

acceptance criteria are unclear
an exception wasn’t defined
a rule is missing
two stakeholders interpret the requirement differently

The code may be waiting for understanding.

3. Dependency unfinished

Your team is done with its part.

But you are waiting for:

another team
an API
infrastructure
test environment
vendor
reference data
approval

The story is technically “in progress,” but the work remaining sits somewhere else.

4. Testing unfinished

Development may be complete.

But behaviour hasn’t been proven.

Maybe:

test data is missing
QA environment is broken
test cases are unclear
defects remain
business validation hasn’t happened

Different problem.

Different owner.

5. Scope unfinished

This one is sneaky.

Every time somebody touches the story, something else gets added.

“While we’re here, can we also…”

Then:

“This edge case should probably be included.”

Then:

“We should support another market too.”

The story is not finishing because the finish line keeps moving.

6. Decision unfinished

Someone needs to choose.

Option A or B.

Approve or reject.

Include or exclude.

Fail or continue.

But no one has clearly made the decision.

This is what happened to ABC-142.

And it’s incredibly common.

If a story keeps coming back, this is the first thing I’d try to identify.

Six ways a story can be unfinished — and why “carried over” does not tell you which one.

Back to ABC-142

Now that we know the blocker, the next step becomes obvious.

Instead of saying:

“Still pending QA.”

we update the story:

Blocker

Expected behaviour is undefined when the upstream Risk Service returns no customer record.

Decision required

Should the transaction:

A. Continue processing without risk data?

B. Stop processing and display an error?

Decision owner

Risk Operations

Impact

QA cannot complete Scenario AC-07 until expected behaviour is confirmed.

Owner

Business Analyst

Now the problem is visible.

That alone is an improvement.

A vague red status has become a specific decision.

Then ask whether this should still be one story

There is another question worth asking after multiple carry-overs:

Is this actually still one coherent piece of work?

Imagine ABC-142 contains:

new UI
backend service
API integration
data migration
reporting change
audit logging
five market-specific rules

And six of those things are finished.

At some point, keeping everything inside one story stops helping.

Maybe completed scope can be separated.

Maybe the unfinished part deserves its own ticket.

Maybe the original story was simply too large.

The point isn’t to split stories just to improve metrics.

The question is:

Does keeping all of this together still help us understand and deliver the work?

If not, restructure it.

Check whether the story changed while people were building it

Now look at the history.

What did ABC-142 look like in Sprint 1?

What does it look like now?

Maybe acceptance criteria were added during Sprint 2.

Another market was added in Sprint 3.

An exception appeared during QA.

A reporting change was added last week.

This is useful because sometimes a story hasn’t “taken four sprints.”

Four different versions of the story have taken four sprints.

That is a different problem.

Look at:

description history
acceptance-criteria changes
newly added scope
comments containing decisions
linked defects
new dependencies

If the requirement keeps changing after implementation starts, call that out.

Don’t hide it inside the carry-over number.

Ask whether QA found a defect or a missing requirement

This distinction matters.

Suppose QA says:

“The system doesn’t show a warning when the upstream response is empty.”

Was a warning required?

If yes:

Defect.

The implementation failed to meet an agreed requirement.

If nobody had ever decided what should happen:

Requirement gap.

Those should not be treated as the same thing.

Otherwise teams end up logging defects against behaviour nobody actually specified.

And that creates a strange cycle:

The cycle

Missing requirementLogged as defectDeveloper asks what correct behaviour isBusiness decision neededStory carries over again

Name the real problem.

Find the owner of the blocker

“Waiting for business” is not ownership.

“Blocked by another team” is not ownership.

“Pending clarification” is not ownership.

Ask:

Who is the person responsible for getting the next answer or action?

Not necessarily the person who must make the decision.

For ABC-142:

Risk Operations owns the decision.

But the BA might own getting that decision.

That means:

Decision owner: Risk Operations
Next-action owner: BA
Next action: Arrange decision with Risk Operations
Due: Tuesday

Now something can move.

The five-minute carry-over test

The next time a story arrives in another sprint, ask these five questions.

1. What exactly is unfinished?

Be specific.

Not:

“Testing.”

Instead:

“QA cannot complete AC-07 because expected empty-response behaviour is undefined.”

2. Why is it unfinished?

Find the type of blocker.

Technical?

Requirement?

Dependency?

Testing?

Scope?

Decision?

3. Who or what are we waiting for?

Name it.

Person.

Team.

System.

Environment.

Decision.

4. Can the completed part be separated?

Maybe yes.

Maybe no.

But ask.

Keeping finished work trapped inside one enormous story may not help anyone.

5. What is the next concrete action?

Not:

“Follow up.”

Something real.

“Risk Operations to confirm fail-vs-continue behaviour by Tuesday.”

Now you can actually manage it.

What happened to ABC-142?

Risk Operations eventually confirms:

If no customer risk record is returned, processing must stop and the transaction should enter Manual Review.

Good.

Now we update the requirement.

Business Rule

Transactions without an available customer risk record must not proceed automatically.

Acceptance Criterion

Given no customer risk record is returned
When transaction validation runs
Then processing stops
And the transaction enters Manual Review status.

QA tests it.

Passes.

ABC-142 closes.

The development work wasn’t the thing that took four sprints.

The unanswered behaviour did.

That distinction matters.

A story can be green and still be stuck

This is another trap.

Teams often use Jira status as shorthand for health.

To Do.

In Progress.

Testing.

Done.

But the status doesn’t tell you whether understanding is moving.

A story can sit in “In Progress” while absolutely nothing useful happens for ten days.

So when something carries over repeatedly, ignore the status for a minute.

Ask:

What changed on this story during the last sprint?

Was a decision made?

Was a blocker removed?

Was a dependency delivered?

Was something tested?

Was scope clarified?

If the answer is basically nothing, moving it into another sprint will not magically change that.

Don’t automatically blame estimation

Sometimes the team simply underestimated the work.

Of course.

But repeated carry-over can also be a symptom of:

vague requirements
hidden dependencies
delayed decisions
scope creep
poor story splitting
missing test data
environment issues
unclear ownership

If you treat every carry-over as “bad estimation,” you may spend hours adjusting story points while the real blocker sits untouched.

That’s why diagnosis comes first.


**Core question:** how do you actually know when something is done?

## The metaphor: a handshake vs. a contract

A user story without acceptance criteria is a handshake deal. Both sides nod, both sides believe they agree, and both sides walk away with a slightly different picture of what was promised — which only becomes visible once the work is "done" and it doesn't match what either side remembers agreeing to. Acceptance criteria are the contract version of that same handshake: written down, specific, and checkable by someone who wasn't in the room when the deal was made.

 Callout type="insight" title="A shared assumption isn't a shared understanding" 
Two people can nod at the same sentence and picture two different outcomes. Acceptance criteria exist to force that gap into the open before the work starts, not after it ships.
 /Callout 

## Given / When / Then is the actual unit of "done"

The useful structure is a precondition, a trigger, and an outcome: *given* the account is locked, *when* the user requests a password reset, *then* a reset link is emailed and the lock stays in place until it's used. Each clause is independently testable — a QA engineer, a developer, and the original stakeholder can all check the same sentence against the same built feature and reach the same yes-or-no answer. That's the entire point: acceptance criteria aren't documentation, they're a test someone can actually run.

 Callout type="question" 
Could two different engineers, working independently, build testably identical things from this criteria alone? If the answer depends on both of them happening to guess the same unstated assumption, the criteria aren't finished yet.
 /Callout 

## Why this matters

"Done" isn't a feeling the team agrees on in a meeting. It's a checklist that was written before the work started, specific enough that no one — not the developer, not the tester, not the stakeholder — has to rely on memory to know whether it was actually met.



**Core question:** why does trade make sense even when one party is better at every single task involved?

## The metaphor: the surgeon and the secretary

A surgeon might type faster than her own secretary — better at surgery *and* better at typing, no contest either way. But every hour she spends typing is an hour not spent in surgery, where her advantage over everyone else is enormous. The secretary's advantage over her at typing is small in absolute terms, but the surgeon's true cost of typing it herself is the surgery she gave up to do it. She hires the secretary anyway — not because the secretary types better, but because the surgeon's time is too valuable to spend on it.

 Callout type="insight" title="It's about opportunity cost, not skill level" 
Trade isn't decided by who's absolutely better at a task. It's decided by who gives up less by specializing in it — and that number can favor the person who's objectively worse at everything.
 /Callout 

## Same logic, whole economies

This is why trade between a highly advanced economy and a less advanced one still benefits both sides, even if the advanced one is better at producing everything it trades. It still gains by specializing in whichever good it gives up the least to produce, and trading for the rest — exactly like the surgeon and her secretary, just at a larger scale.

 Callout type="question" 
Before assuming you should do a task just because you're the best person available for it, ask: what's the opportunity cost of my time doing this, instead of the thing only I can do?
 /Callout 

## Why this matters

Being the best at something is not the same question as whether you should be the one doing it. Comparative advantage is the reminder that the right division of labor is about relative cost, not absolute talent — which is exactly why it keeps surprising people who only ever check who's "better."



**Core question:** what happens if you're right about the trade, but the person on the other side of it can't pay?

## The metaphor: lending a ladder to a neighbor vs. a stranger passing through

The ladder itself doesn't change. Who you lend it to does. Your reliable neighbor gives it back tomorrow without you thinking twice. A stranger passing through town might vanish before returning it, no matter how sturdy the ladder was. Counterparty risk is the same idea applied to a trade: it has nothing to do with whether your market view was correct, and everything to do with whether the entity on the other side of your contract can actually make good on it.

 Callout type="insight" title="Two separate risks, often confused" 
Market risk is about whether the asset moves the direction you expect. Counterparty risk is entirely different — you can be exactly right about the direction and still lose the full value of the trade if the other side defaults before paying you what they owe.
 /Callout 

## This is exactly why clearinghouses exist

A clearinghouse solves the ladder problem by turning every stranger into the same well-known neighbor. It steps into the middle of a trade and becomes the counterparty to both sides — the buyer no longer faces the seller's risk of default, and the seller no longer faces the buyer's. Both face the clearinghouse instead, which pools and manages that risk across its whole membership rather than leaving each trade exposed to whoever happened to be on the other side of it.

 Callout type="question" 
Before a trade, ask not just "will this move the direction I expect" but "if I'm right, can the other side actually pay me when it's due?" The first question is about the market. The second is about who you're actually trading with.
 /Callout 

## Why this matters

A trade isn't just a bet on price. It's also a bet on the solvency of a specific counterparty for however long the contract stays open — and that second bet is invisible until the day it matters, which is exactly when it's too late to do anything about it.



**Core question:** where do trades actually happen, and why does the venue change what the trade means?

## The metaphor: a farmer's market vs. a private phone call

An exchange is a farmer's market: every buyer and seller sees the same posted prices at the same stall, and the trade happens where anyone standing nearby could have watched it. **OTC** — over-the-counter — is a private phone call between two parties instead. The deal terms, and often the price itself, are known only to the two people who made it. Same goods can move through either channel. The venue decides who else gets to know what happened.

 Callout type="insight" title="Public price vs. private deal" 
An exchange trade creates a public price everyone can reference for the next trade. An OTC trade doesn't — which is exactly why complex, bespoke instruments (many swaps, structured products) trade OTC in the first place. No public stall would fit a deal this custom.
 /Callout 

## Same asset, different venue, different price

The exact same stock can move through both channels. Most shares trade on the exchange, at the visible posted price. But a large institutional block of that same stock might get negotiated privately instead — specifically to avoid moving the public price before the trade is even finished. Size and privacy, not the asset itself, often decide which venue a trade uses.

 Callout type="question" 
Next time you see a price quoted, ask: was this posted on an exchange, where anyone could have gotten the same number — or was it negotiated OTC, between two specific parties who agreed to it privately?
 /Callout 

## Why this matters

The venue isn't a technical detail — it's the difference between a price the whole market can react to and a price only two people will ever see. Regulation, liquidity, and even how confidently you can trust a quoted number all trace back to which of these two a trade actually went through.



**Core question:** if no single authority sets a price, how does a price ever actually get discovered?

## The metaphor: not an announcement, a running poll

Every incoming order is a fresh vote about what an asset is worth right now, cast by someone willing to back their opinion with real money. Price discovery isn't a single event where a number gets declared — it's a running tally of a poll that never closes. The "current price" is just whichever vote most recently won.

 Callout type="insight" title="The price is a tally, not a fact" 
Nobody announces that a stock is now worth a different amount. The price simply reflects the latest vote in a poll that's been running continuously since the market opened — stable-looking only because the votes usually agree with each other.
 /Callout 

## News moves price precisely because it changes votes

New information doesn't move a price directly — it moves what buyers are willing to pay and what sellers are willing to accept, and the price shifts because the votes themselves changed. A sharp move after an earnings report isn't the market "reacting" in the abstract. It's thousands of individual votes flipping at once, and the tally updating to match.

 Callout type="question" 
When a price moves sharply, ask what information could have just changed enough people's votes at the same moment — that's usually easier to find than trying to explain the price move directly.
 /Callout 

## Why this matters

Treating a price as a fixed, authoritative number instead of a live poll result is where a lot of bad intuitions about markets come from. A price didn't get decided. It's still being voted on, right now, and it will keep changing the moment enough votes do.



**Core question:** what should be built first, when everything feels urgent?

## The metaphor: triage in an emergency room

An ER doesn't treat patients in the order they arrived. It treats them in order of what happens if they wait — a broken finger and a chest pain case might arrive at the same moment, but nobody seriously suggests treating them first-come-first-served. Prioritizing a backlog is the same triage, not a queue: the order tickets arrived in tells you almost nothing about the order they should be worked in.

 Callout type="insight" title="Loudest voice isn't most critical" 
"Urgent" and "important" get conflated constantly on a backlog. The stakeholder who escalates the hardest doesn't automatically have the item that costs the business the most by waiting — they just have the most confidence, or the most patience for meetings.
 /Callout 

## Value and effort are the only two axes that matter

Every item on a backlog can be placed on two axes: how much value it delivers, and how much effort it takes to deliver. High value, low effort items are the ones triage would send straight to the front — the equivalent of a five-minute fix that stops the bleeding. Low value, high effort items belong at the back regardless of who's asking, no matter how urgently they're asking for it. Prioritization frameworks (MoSCoW, weighted scoring, whatever the team uses) are just formal ways of forcing that comparison instead of letting whoever asks loudest win by default.

 Callout type="question" 
For any item near the top of the backlog, ask: what actually happens if this waits one more sprint, and who notices? If the honest answer is "nothing, and no one," it isn't triage-first — it just arrived first.
 /Callout 

## Why this matters

A backlog ordered by arrival time or by who complained most recently isn't prioritized — it's just a log. Real prioritization means being able to explain, for the item at the top, specifically what gets worse if it waits — the same way an ER can explain why the chest pain goes first, not just that it does.



**Core question:** why does the problem you solve matter more than how well you solve it?

## The metaphor: a doctor who prescribes before diagnosing

A patient walks in and says "I need antibiotics." A bad doctor writes the prescription. A good doctor asks what's actually wrong first — because "I need antibiotics" is already a diagnosis the patient made themselves, and patients are usually wrong about what's actually causing their symptoms. Stakeholders do the same thing constantly: "we need a dashboard," "we need a new system," "we need an approval workflow." Each one is a prescription arriving before anyone confirmed the diagnosis.

 Callout type="insight" title="The most expensive words in a requirements meeting" 
"We need a system that..." is already a solution. It skips the one question that would have told you whether it's the right one: what problem is this actually solving, and does the system even solve it?
 /Callout 

## The requested solution has already made three decisions

By the time a stakeholder names a fix, they've silently already decided its shape, its technology, and who's responsible for it — all before the actual problem was ever said out loud. Accept the request as stated and you've inherited three decisions nobody actually examined. Walk it back to the problem first, and some of those three might turn out wrong: the right fix might be a process change, not a system; a policy change, not a dashboard.

 Callout type="question" 
Next time a request arrives starting with "we need X," ask what happens today without X. The gap between those two answers is the actual problem — X was just someone's first guess at closing it.
 /Callout 

## Why this matters

A solution chosen before the problem is understood tends to treat the stated symptom while leaving the underlying cause untouched. It still gets built, on time, to spec — and it still doesn't fix anything, because nobody ever confirmed it was aimed at the right target in the first place.



**Core question:** how do you give a model access to information it never studied, without retraining it from scratch?

## The metaphor: an open-book exam vs. a memorized one

A model that was trained on a fixed dataset is taking a closed-book exam — it only knows what it studied before the exam started, frozen at that point. **RAG** — Retrieval-Augmented Generation — is an open-book exam instead: at question time, the model gets handed the specific pages relevant to *this* exact question, pulled fresh from a library it never had to memorize. It doesn't need to know everything in advance. It just needs to know how to look up the right page and read it.

 Callout type="insight" title="The model doesn't change — only what it's shown does" 
RAG doesn't retrain the model at all. It changes what gets placed in front of it at question time, which is exactly why it's the easy way to keep answers current: add a new page to the library, and it's searchable immediately, with no retraining required.
 /Callout 

## The default for anything that changes, or shouldn't be memorized

This is why RAG is the standard choice for internal company documents, this week's data, or anyone's private files — a closed-book exam can't cover material that didn't exist when the studying happened, no matter how good the studying was. Fine-tuning a model's weights is for teaching a stable style or skill. RAG is for handing it facts that are still changing, or that were never meant to live inside the model itself.

 Callout type="question" 
Before assuming a model should just "know" something, ask whether it's actually stable, general knowledge worth memorizing — or something that should be looked up fresh every time because it changes, it's private, or it's simply too large to bake in.
 /Callout 

## Why this matters

The instinct to fix a knowledge gap by retraining the model is usually the expensive, slow answer to a problem RAG solves in minutes. Most "the model doesn't know X" problems aren't training problems at all — they're retrieval problems, solved by handing over the right page instead of trying to make the model memorize the whole library.



**Core question:** should every decision get the same amount of deliberation?

## The metaphor: one-way doors and two-way doors

A one-way door only opens in one direction — walk through, and there's no walking back. A two-way door is different: if it turns out to be the wrong room, you just walk back through and try another. Decisions work the same way. Some are one-way doors, where a wrong call is expensive or impossible to undo, and deserve careful, slow, well-consulted deliberation. Most are two-way doors, where being wrong just costs a course correction — and treating them like one-way doors is where a lot of organizational slowness actually comes from.

 Callout type="insight" title="Most decisions get treated like the rare ones" 
Endless meetings and sign-offs for a decision that's trivially reversible aren't carefulness. They're slowness borrowing the appearance of diligence from the rare decisions that actually deserve it.
 /Callout 

## The real skill is sorting, not deciding

Before deliberating on a decision at all, the first move is classifying it: can this be undone cheaply if it's wrong? If yes, decide fast, often by one person, and correct course later if needed — the cost of being wrong is low, so the cost of deciding slowly is pure waste. If no, slow down deliberately and gather more information first, because there's no "try again" available once you're through that door. The speed of a decision should match how reversible it is, not how big or important it feels in the moment.

 Callout type="question" 
Before scheduling another meeting about a decision, ask: if we're wrong, how expensive is it to reverse? If the honest answer is "trivial," the meeting is already costing more than the decision itself.
 /Callout 

## Why this matters

Organizations don't usually get slow because people are lazy. They get slow because every decision gets sorted into the "irreversible" bucket by default, out of caution — and caution applied to a decision that was never actually risky isn't caution. It's just cost, dressed up as prudence.



**Core question:** why do good decision-makers treat a coin flip completely differently from a genuinely unknown future?

## The metaphor: a labeled deck vs. an unlabeled one

**Risk** is a deck of cards where you know exactly what's in it — you might not know which card comes next, but you know the odds. Insurance, casino games, and most everyday probability puzzles are risk: the deck is labeled, even if any single draw is uncertain.

**Uncertainty** is a deck where you don't even know what's in it — new categories of cards you've never seen, or cards that don't exist yet. Launching a genuinely new product, predicting a novel technology's effect on a market, forecasting a one-off geopolitical event — these aren't risk. There's no stable deck to calculate odds from.

 Callout type="insight" title="Confusing the two is the actual mistake" 
Treating uncertainty as if it were risk — assigning confident percentages to things that are fundamentally unknowable — is where most bad forecasts come from. The math looks rigorous. The deck was never labeled.
 /Callout 

## Why this distinction changes behavior

Under risk, the right move is to calculate expected value and act on it — the odds are real, so trust the math. Under uncertainty, the right move is different: build in optionality, run small reversible experiments, and stay able to change course, because no calculation can tell you the "true" odds of something that's never happened before.

 Callout type="question" 
Before trusting a forecast, ask: is this a labeled deck, or an unlabeled one? The confidence in the delivery tells you nothing about which one it is.
 /Callout 

## Why this matters

Good decision-makers don't have better crystal balls. They're just more honest about which situations are a labeled deck and which ones aren't — and they stop demanding false precision from the ones that aren't.



**Core question:** why does a price settle where it does, instead of anywhere else?

## The metaphor: two crowds pushing on a door

Picture a door with people pushing from both sides. On one side, buyers push harder the cheaper the price gets — more people want in at a bargain. On the other side, sellers push harder the more expensive it gets — more people are willing to sell if the reward is bigger. The door settles wherever the two pushes exactly cancel out. That resting point is the price.

Push either crowd harder — more buyers show up, or sellers become scarcer — and the door slides to a new resting point. Nobody decided the new price. It's just where the pushing balances again.

 Callout type="insight" title="Price is a byproduct, not a decision" 
No single person sets the market price of wheat, oil, or a stock. It emerges from thousands of independent pushes finding their balance point — which is why prices can shift overnight without anyone "deciding" to change them.
 /Callout 

## Why shortages and gluts are the same phenomenon

A shortage is just the door stuck too far toward the buyers' side — the price is artificially low, so more people want in than the sellers' side can supply. A glut is the mirror image: price stuck too high, sellers piling up with no buyers pushing back. Both are the same mechanism, just displaced from the balance point — usually by something external holding the price fixed (a price cap, a subsidy, a shock to supply).

 Callout type="question" 
Next time you see a shortage in the news, ask: is demand suddenly rising, or is something stopping the price from finding its natural balance point?
 /Callout 

## Why this is worth understanding

Once you see price as a balance point rather than a fixed fact, a lot of economic behavior stops being mysterious: why gas prices spike during shortages, why concert tickets get scalped, why a heatwave moves the price of ice cream. It's always the same two crowds, pushing.



**Core question:** out of everything an organization *could* build, why does it build this instead of that?

## The metaphor: a scale, not a checklist

A business case isn't a list of reasons something is good — almost anything can be justified with a long enough list of upsides. It's a scale, with cost and risk on one side and value on the other, built to be checked *against a specific alternative*: doing nothing, or doing the next-best thing on the list. A business case that never names its alternative isn't really a case for anything — it's just enthusiasm.

 Callout type="insight" title="The real competitor is usually 'do nothing'" 
Most business cases quietly compare an idea to nothing at all, when the real competition is every other initiative fighting for the same budget and the same engineering time this quarter.
 /Callout 

## The four things a real business case answers

- **What changes if we do this?** — the measurable outcome, not the feature list.
- **What does it cost, including the cost of *not* doing something else?**
- **What has to go right for the value to actually show up?** — the assumptions the case is quietly resting on.
- **How would we know, after the fact, whether it worked?**

 Callout type="question" 
If you can't answer the fourth question before the project starts, ask whether anyone will actually check afterward — or whether "success" will just be declared by default.
 /Callout 

## Why this matters

The organizations that build the right things aren't the ones with the best ideas — everyone has good ideas. They're the ones that can weigh ideas against each other honestly, using the same scale every time, instead of whichever argument was pitched most persuasively in the room.


Jira Hacks for Business Analysts

Acceptance Criteria Playbook

First Time Writing a User Story

The Story Has Been Carried Over for Four Sprints