BA Playbook
The Story Is Done. Why Can't We Release It?
Jira says Done. Production says not yet. Here's the gap between the two.
Surya · August 14, 2026 · 4 min read · 10 practices
For Business Analysts who keep hearing "not yet" after Jira turns green, Product Owners deciding what "done" actually means for a story, Delivery leads tracing why a finished feature still can't ship and QA and developers who want release blockers visible before go-live, not during it.
The developer has finished coding. QA has tested it. Acceptance criteria are green. Jira says DONE. So you ask: "Great, can we release it?" And someone replies: "Not yet." Why? Because story completion and release readiness are not the same thing. A feature can work perfectly and still be unsafe or impossible to release. Imagine an insurance platform introducing a new claim-status feature: Submitted → Under Review → Approved → Rejected. Development is complete, QA passes every acceptance criterion, the demo looks perfect — but release is blocked. Production reference data isn't ready. A downstream API is still on the older version. Operations hasn't received the new process. Monitoring doesn't cover the integration. A security review is still open. The feature works. The release path doesn't. "Done" means something different to everyone in the room: code complete to the developer, testing passed to QA, acceptance criteria satisfied to the Product Owner, safe to deploy to Release Management, I can use it to the customer. So when someone says "the story is done," ask done for whom — and ready for what? Then trace the release path through eight gates.
01Gate 01
ACCEPTANCE — Did we build the right thing?
A green checkbox in Jira isn't proof. It's a claim that still needs checking.
Gate 01
ACCEPTANCE — Did we build the right thing?
A green checkbox in Jira isn't proof. It's a claim that still needs checking.
At a glance
- Was the expected behaviour actually demonstrated?
- Are the important edge cases covered?
- Were business rules interpreted correctly?
- Has the right business owner validated the result?
Why it helps
If people still disagree about expected behaviour, the story isn't ready — no matter what the ticket status says.
02Gate 02
TESTING — Have we proved enough?
Functional testing passing doesn't mean enough testing has happened.
Gate 02
TESTING — Have we proved enough?
Functional testing passing doesn't mean enough testing has happened.
Not every story needs everything on this list. Ask what evidence is appropriate for the risk of this change — a button-text change and a payment-engine change shouldn't face identical gates.
At a glance
- Integration testing
- Regression testing
- UAT
- Performance testing
- Security testing
- Accessibility testing
- Resilience testing
Why it helps
Matching the testing depth to the actual risk is what keeps this gate fast for small changes and thorough for the ones that can't afford to be wrong.
03Gate 03
DEPENDENCIES — Is everything around the story ready?
Your ticket can be 100% complete while the capability it delivers is only 80% ready.
Gate 03
DEPENDENCIES — Is everything around the story ready?
Your ticket can be 100% complete while the capability it delivers is only 80% ready.
At a glance
- Another story
- Another team
- An API
- A vendor
- Infrastructure
- Reference data
- A database change
- An approval
- A feature flag
Why it helps
Ask what has to be true outside this story for the customer journey to actually work — that question surfaces the dependency before it becomes a release-day surprise.
04Gate 04
NON-FUNCTIONAL — Can it survive Production?
A feature can work perfectly for one tester and still fail in the real world.
Gate 04
NON-FUNCTIONAL — Can it survive Production?
A feature can work perfectly for one tester and still fail in the real world.
Compare
Functional testing asks
"Does it work?"
Release readiness asks
"Can we operate it safely?"
At a glance
- Performance — what happens under real load?
- Security — are access and vulnerabilities addressed?
- Availability — what happens when a dependency fails?
- Auditability — can important actions be traced?
- Accessibility — can intended users use it?
- Recovery — can the team recover safely?
Why it helps
These are two different questions with two different answers — a story can pass the first and still fail the second.
05Gate 05
DATA & CONFIG — Is Production prepared?
Sometimes the code is fine. The environment isn't.
Gate 05
DATA & CONFIG — Is Production prepared?
Sometimes the code is fine. The environment isn't.
What actually broke
At a glance
- Configuration
- Feature flags
- Reference data
- Permissions
- Certificates / secrets
- Database changes
- Migration scripts
- Production data assumptions
Why it helps
Checking this gate before go-live catches the exact class of failure that no amount of extra functional testing would ever have caught.
06Gate 06
SIGN-OFF — Have the right people approved?
Release day is the wrong time to discover an approval was never asked for.
Gate 06
SIGN-OFF — Have the right people approved?
Release day is the wrong time to discover an approval was never asked for.
At a glance
- Product
- Business
- Operations
- Risk
- Compliance
- Security
- Legal
- Architecture
- Release Management
Why it helps
The BA does not need to own every approval. But the BA should know which ones affect the business outcome — before silence at the release meeting is the first sign one is missing.
07Gate 07
DEPLOYMENT — Can we actually release it?
A good feature with a bad deployment plan is still a risky release.
Gate 07
DEPLOYMENT — Can we actually release it?
A good feature with a bad deployment plan is still a risky release.
At a glance
- What is the deployment sequence?
- Are scripts ready?
- Which dependency goes first?
- Is downtime required?
- Is a feature flag involved?
- Can we roll back?
- Is migration reversible?
- Who makes the go/no-go decision?
Why it helps
Every one of these questions is cheap to answer before release and expensive to answer during an incident.
08Gate 08
MONITORING — What happens after go-live?
Release isn't the end of delivery. It's the beginning of real usage.
Gate 08
MONITORING — What happens after go-live?
Release isn't the end of delivery. It's the beginning of real usage.
The scenario to avoid
At a glance
- What are we monitoring?
- What triggers an alert?
- Who receives it?
- What does Support need to know?
- Is there a runbook?
- Who owns issues after go-live?
Why it helps
Answering these before release turns a 10:15 PM surprise into a 10:15 PM alert with an owner already attached.
09Gate 09
Trace the path, don't just report the status
"The story is stuck" creates confusion. A traced status creates action.
Gate 09
Trace the path, don't just report the status
"The story is stuck" creates confusion. A traced status creates action.
Compare
Vague framing
"The story is stuck."
Traced framing
"The feature is functionally complete. Release is blocked because the Production certificate hasn't been provisioned."
At a glance
- Acceptance — Ready
- Testing — Ready
- Dependencies — Ready
- Security — Ready
- Production configuration — Blocked: certificate missing
Why it helps
A bank's beneficiary-validation feature hit exactly this: Jira said Done, functional testing passed, but release was blocked. Tracing the eight gates found the one unmet condition in fifteen minutes instead of a week of "why isn't this live yet?"
10Gate 10
Name the blocker type, not the person to blame
Don't ask whose fault this is. Ask what condition for safe release is still unmet.
Gate 10
Name the blocker type, not the person to blame
Don't ask whose fault this is. Ask what condition for safe release is still unmet.
At a glance
- Process — missing approval, change gate, documentation or policy requirement
- Technical — environment mismatch, feature flag, defect or dependency
- Data — reference data, migration or data-quality concern
- People — approver unavailable or ownership unclear
- External — vendor or third-party dependency
- Risk — security concern, critical defect or insufficient testing
Why it helps
Most Done-but-not-released stories fall into one of these six buckets — naming the bucket points straight at who needs to act, instead of starting a blame conversation that doesn't move the release forward.
Pro tip — During refinement, ask: "What could stop this from reaching Production even if we build it correctly?" That question exposes dependencies, approvals, data changes, security needs and operational requirements while they're still cheap to fix.
Done for the team
is not the same as ready for the customer.
Jira is a workflow tool. It is not Production. A green ticket can tell you the team's work on this story is complete. It cannot always tell you customers can safely use this tomorrow. So when someone asks "the story is Done, why can't we release it?" — don't stare at the status. Trace the release path. Find the unmet condition. Remove the blocker early. A good BA doesn't just help a story reach Done. A good BA helps the value reach Production safely.
Take this with you
Release Readiness Checklist
RELEASE READINESS CHECKLIST [ ] Acceptance criteria are validated. [ ] Required testing is complete. [ ] Critical defects are resolved or accepted. [ ] Dependencies are ready. [ ] Required non-functional checks are complete. [ ] Production data/configuration is ready. [ ] Required approvals are obtained. [ ] Deployment steps are understood. [ ] Rollback/recovery is understood. [ ] Monitoring and alerts are ready. [ ] Operations/Support understand the change. [ ] Post-go-live ownership is clear.
Get new playbooks first.