See test execution and QA management in action. Read the comparison doc.

Three phases of gap analysis: acceptance criteria coverage, orphan code detection, and quality gaps. On average, 40+ gaps per project. Evidence, not opinion.

The question nobody can answer

In every release standup, the CTO asks: "Are we shipping something incomplete?"

The answer is always a guess. "I think we covered all the requirements." "Pretty sure there is no orphan code." "The code looks clean to me."

But you do not know. Not really. You have opinions. You do not have evidence.

Gap analysis is the evidence. It answers three critical questions:

• Are all our acceptance criteria actually implemented in the code?

• Do we have code that has no requirement behind it (orphan code)?

• Do we have quality or security issues that are not yet tracked?

Every other quality tool answers "is this broken?" Gap analysis answers "did we build what we said we would build?"

The three phases of bidirectional gap analysis

Phase 1: Acceptance Criteria to Code (Story to Code)

You have a user story. It has acceptance criteria. The code is supposed to implement those criteria. Phase 1 answers: does it?

Gap analysis reads every acceptance criterion. It reads the code. It checks: is this criterion actually implemented?

The result: a list of acceptance criteria that are not implemented. These are hard gaps. You said you would do it. You did not.

Example: Story ABC-123 says: "A user can delete their account. All data is purged within 30 days." The code deletes the account. But nothing purges the data. Gap found: GDPR requirement not met.

Phase 2: Code to Story (Orphan Code Detection)

The flip side: you have code. Is all of it tied to a requirement?

Phase 2 reads the code. It looks at every function, every module, every feature flag. It asks: is this connected to an acceptance criterion or a story?

The result: a list of code that has no requirement backing it. These are orphan code. You built something nobody asked for. Or a requirement changed but the code was never deleted.

Example: A payment retry module exists in production. But no requirement specifies retry behavior. Gap found: code without requirement. Liability risk, maintenance burden.

Phase 3: Quality and Security Gaps (AST Analysis)

Phase 1 and 2 check coverage. Phase 3 checks quality. Using abstract syntax tree analysis, gap analysis inspects the code for:

• Hardcoded secrets or credentials

• SQL injection vulnerabilities

• Missing error handling

• Unvalidated user input

• Race conditions in concurrent code

These are gaps in your quality and security posture. They are not requirements that were not met. They are engineering practices that were not followed.

Example: Phase 3 finds: database queries that concatenate user input (SQL injection risk). Gap found: security practice not implemented.

Why bidirectional matters

Unidirectional gap analysis (just Phase 1) is incomplete. It tells you what you did not build. It does not tell you what you built that you should not have.

Bidirectional gap analysis goes both directions. Story to code. Code to story. You get a complete picture.

That completeness is why the average project has 40+ gaps. Most teams have never looked in both directions. When they do, the gaps are everywhere.

What these gaps actually cost

Every unimplemented acceptance criterion is a feature working partially or not at all. An incomplete release.

Every piece of orphan code is maintenance burden. Dead code you have to carry. Security surface area you did not know about.

Every quality gap is a defect waiting to happen. Code that looks fine until someone tries to use it in an unexpected way.

Real cost: A team found 23 unimplemented acceptance criteria in their payment module. Three of them were critical. They shipped incomplete. Post-release fixes cost 3x more than pre-release fixes.

How to use gap analysis for evidence

Run gap analysis before every release. Ask:

• How many acceptance criteria are still unimplemented? (Phase 1)

• How much orphan code exists? (Phase 2)

• What quality issues are we shipping with? (Phase 3)

Use these numbers as evidence. "We have 5 unimplemented criteria. We need to either implement them or remove them from the release." That is a decision, not an opinion.

Gap analysis for different audiences

For CTOs and engineering leaders

Gap analysis is your release checklist. Before you approve a release, you know exactly what is missing. You can decide: do we fix it? Do we defer it? Do we accept the risk?

For QA directors

Gap analysis is your test plan. Use Phase 1 to know which acceptance criteria need tests. Use Phase 2 to know which code exists that might not be tested.

For compliance and audit teams

Gap analysis is your audit trail. You can prove: every requirement was evaluated. Every piece of code was examined. Every quality issue was found and addressed.

For product managers

Gap analysis is your delivery confidence. High gap count means you will ship incomplete. Low gap count means you are ready.

The math of gaps

On average, projects have 40 to 60 gaps per major release. That includes:

• 15 to 20 unimplemented acceptance criteria

• 10 to 15 pieces of orphan code

• 15 to 30 quality or security gaps

These are not failures. They are normal. Every team has gaps. The difference is whether you know about them before you ship or after.

Next steps

This week, we are diving deeper into gap analysis:

• How to interpret unimplemented requirements

• How to handle orphan code

• How to prioritize security and quality gaps

For now: think about your last release. Do you know how many gaps were in it? Could you answer that question with evidence or just opinion?

See your gaps. Run bidirectional gap analysis on your next release. Book a walkthrough.