“We’ll Fix It in the Next Sprint” Is a QA Smell

The Sentence That Quietly Kills Quality

There is a sentence that quietly kills Salesforce quality long before a feature ever hits Production. It isn't a technical error message, and it isn't a user complaint. It’s a project management decision:

“Let’s just fix it in the next sprint.”

It sounds reasonable. It sounds like "Agile" prioritization. It sounds harmless.

It is none of those things.

In the fast-paced world of Salesforce implementation, where configuration changes are cheap and deployments are frequent, teams often fall into the trap of treating defects as temporary inconveniences rather than risk indicators. But when a QA engineer raises a red flag and the response is to defer it, you aren't just moving a Jira ticket. You are planting a landmine.

What Actually Gets Deferred?

When a defect is pushed to the backlog, we tell ourselves we are deferring the work. In reality, we are deferring the understanding.

Salesforce logic is highly contextual. A Flow works a certain way because of a specific business requirement valid right now. A Validation Rule exists to protect data quality for a specific integration running today.

When you postpone the fix:

• You lose the root cause analysis.
• You lose the mental model of the affected logic.
• You lose the validity of your current assumptions.

By the time the team picks that ticket up three sprints later, the context has faded. The defect has transformed from "a bug we understand" to "legacy behavior we are afraid to touch."

Salesforce Amplifies Deferred Defects

In traditional software development, a bug in a compiled binary is bad. In Salesforce, a bug in metadata is contagious.

Salesforce architecture relies on layers of interacting configuration: Automation (Flow/Apex), Security (Sharing/Profiles), and Data Integrity (Validation/Duplicate Rules). These layers stack.

A small defect deferred in Sprint 1 (e.g., "This Validation Rule fires incorrectly for the Integration User") forces a workaround in Sprint 2 (e.g., "Let’s just turn off the rule for that Profile").

By Sprint 4, that workaround has become a dependency for a new Process.
By Sprint 6, it’s a production incident during a release freeze.

The defect didn't grow on its own. It grew because the system was built around the defect rather than fixing it.

How to Detect the Smell

You can hear this failure mode in your stand-ups and refinement sessions. It disguises itself in phrases like:

• “That’s an edge case.”
• “Business says they can live with it for now.”
• “That scenario is rare.”

In Salesforce, "Edge Case" is usually code for "Unmodeled Logic Path."

If a user can do it, they will do it. If a Record Type can enter that Flow, it eventually will. Dismissing these as rare does not remove the logic path; it just leaves it unguarded.

The Compounding Effect

The danger is not that the defect exists. The danger is that everyone forgets why it exists.

Deferred QA issues have a nasty habit of becoming normalized. They stop being "bugs" and start being "system behavior." New developers build features assuming that the broken behavior is intentional.

Eventually, someone asks:

“Why does the Opportunity Stage revert to 'Prospecting' when I edit the Description?”

And the terrifying answer is: No one knows. The ticket that explained it was deferred six months ago and buried under a mountain of user stories.

QA Takeaways: From Deferral to Decision

Strong QA doesn't argue for perfection. We know that deadlines exist and go-live dates are real. However, we must argue for decision clarity.

If a defect is deferred, QA must force the team to move away from "we'll get to it" and towards explicit risk management.

• Force Explicit Acceptance: Do not let the Product Owner simply move the ticket. Make them type out: "We accept the risk that [Scenario X] will fail in Production."
• Define the Scope: Ensure the ticket documents exactly what is broken. Don't write "Fix Flow." Write "Fix decision element A to account for null values."
• Set a Revisit Trigger: A deferred bug without a due date is a deleted bug. Tag it with a specific release or date where it must be addressed.

The Real Problem

Deferred quality is not just technical debt. It is forgotten intent.

"We’ll fix it in the next sprint" is rarely a promise. It’s usually an abandonment of quality. As testers, our job is to ensure that if a bug is left behind, the team knows exactly what price they will pay for it later.

Do you have a "deferred" bug in your backlog that has effectively become a permanent feature? How do you handle pushback on "minor" defects?