Scrum + SQA + RSM: Helpful Quality Loop or Just Redundant Process?

If your team already “does Scrum” but you still ship bugs, scramble before Sprint Review, and keep paying interest on technical debt… you’re not alone.

Scrum is great at delivery cadence. But Scrum intentionally doesn’t tell you how to engineer quality: test strategy, quality gates, risk-based testing, automation, CI/CD, code review discipline, and so on.

That gap is exactly why people try to “attach” an SQA framework to Scrum. One popular structure is RSM:

Recognize → Scrutinize → Materialize

Sounds solid, right?

It is… but only if it’s positioned correctly. If not, it becomes redundant and slows the sprint down.

In this article, I’ll break down:

• what RSM really means in a Scrum + SQA context,
• why it often feels like DoR/DoD in disguise,
• when it adds real value,
• and how to implement it without turning Scrum into a mini-waterfall.

Photo by Eden Constantino on Unsplash

Why Scrum Often “Leaks” Quality

Let’s be honest: many teams do Scrum events religiously… but still struggle with quality because:

• acceptance criteria are vague or missing
• testing happens at the end of the sprint (or worse, after the sprint)
• Definition of Done is a poster, not a gate
• technical debt quietly grows sprint by sprint
• bugs are discovered in UAT or production instead of earlier

That’s not Scrum failing. That’s engineering practices not being explicit and consistent.

Scrum is a framework for managing work. Quality still needs a system.

What Is RSM (Recognize–Scrutinize–Materialize) in SQA?

In a Scrum + SQA proposal, RSM usually represents a repeatable quality loop:

1) Recognize

Identify what matters early:

• requirements (what “done” means)
• risks (what can go wrong)
• quality expectations (DoD / quality criteria)

2) Scrutinize

Validate and inspect:

• is it testable?
• is it feasible?
• are we missing edge cases?
• what’s the minimal quality bar for this item?

3) Materialize

Turn it into real quality, not documents:

• implement
• test
• automate checks
• enforce gates
• ship an increment that’s actually releasable

On paper: ✅ perfect.

In real teams: there’s a trap.

“This Looks Like Definition of Ready (DoR), Doesn’t It?”

Yes. That’s why many practitioners say RSM is redundant.

• Definition of Ready (DoR) is often used to ensure a backlog item is “ready to be pulled” into a sprint.
• Recognize + Scrutinize (big version) do the same thing: clarity + testability + risk visibility before execution.

If you run Recognize/Scrutinize as a heavy phase during the sprint, you get:

• broken Sprint Goal focus
• scope creep
• more meetings
• slower delivery
• “we’re doing Scrum but it feels like waterfall”

So the issue is not RSM itself.

The issue is where and how you apply it.

Two Types of “Recognize”: Big vs Micro

This is the our rule:

If your framework doesn’t distinguish “big” vs “micro”, it will become process tax.

A) Big Recognize (planning-grade)

This should happen before the sprint starts (or at least be finalized during Sprint Planning).

It’s basically:

• backlog refinement + acceptance criteria
• a touch of risk-based thinking
• agreement on the quality bar (DoD)

B) Micro Recognize (execution-grade)

This happens inside the sprint, because reality exists.

You discover:

• hidden dependencies
• edge cases
• performance constraints
• security concerns
• “oh wow, this breaks the whole flow”

That’s also Recognize — but it shouldn’t become a ceremony.

It should be a lightweight feedback loop, embedded in real engineering work.

Practical rule of thumb

• If it threatens the Sprint Goal or introduces critical risk → handle now
• If it’s improvement / scope expansion / non-critical → backlog it

Photo by Mick Haupt on Unsplash

“If We Recognize During the Sprint, Doesn’t It Slow Us Down?”

It depends on what you mean by “Recognize.”

✅ It won’t slow you down if:

• it’s micro-recognize
• it’s integrated into work (not a new meeting)
• it produces immediate actions (tests, adjustments, mitigation)

❌ It will slow you down if:

• it’s a new phase gate
• it triggers re-planning constantly
• it creates admin work instead of quality work

So yes — your concern is valid.

But the fix is not “never recognize during the sprint.”

The fix is: protect the Sprint Goal and keep RSM lean.

Photo by Lala Azizli on Unsplash

How to Integrate RSM Into Scrum Without Redundant Overhead

1) Don’t add new Scrum events

Map RSM to existing Scrum moments:

• Backlog Refinement → Recognize (big) + early Scrutinize
• Sprint Planning → finalize Scrutinize + commit quality criteria
• Sprint Execution → Materialize + micro-recognize
• Sprint Review + Retro → feedback + update DoD / working agreements

2) Make outputs concrete (or don’t do it)

“Requirements + Risks + DoD” as outputs are too generic.

Real outputs that matter:

• acceptance criteria that are testable
• a tiny risk note (High/Medium/Low + 1 mitigation bullet)
• a quality criterion per story (e.g., “must include integration test”)
• DoD updates based on learning

3) Apply it selectively (risk-based)

Not every backlog item needs the same level of scrutiny.

• High risk: payment, security, compliance, performance → tighter gates
• Low risk: copy change, minor UI tweak → standard DoD

That’s how you keep the system scalable.

Where ISO 9001 and ISO/IEC 25010 Actually Fit

ISO shouldn’t turn Agile into bureaucracy. It should be a lens.

ISO 9001 (quality management mindset)

Useful anchors:

• customer focus
• requirement clarity
• risk-based thinking
• continuous improvement

That aligns nicely with Recognize/Scrutinize — as long as you keep it lightweight.

ISO/IEC 25010 (software product quality)

It helps you define what “quality” means beyond “it works”:

• functional suitability
• reliability
• usability
• performance efficiency
• security
• maintainability
• compatibility

For example:

• login flow → security + reliability are priority
• list screen → usability + performance matter more
• internal admin tool → maintainability might be the main win

A Practical Example (User Stories)

User story:

As a User, I can top up x via x platform, so I can serve x customers.

A lightweight RSM-friendly setup:

• clear acceptance criteria (bullet points or Gherkin)
• minimal risk note: “timeout → require idempotency / status inquiry”
• quality criteria: “transaction recorded in history + reference number exists”

That’s it.

No extra ceremony. Just real quality commitments.

So… Is RSM Worth It or Redundant?

RSM is worth it when:

• quality practices aren’t consistent across teams
• testing always happens late
• risk is ignored until it hurts
• DoD is weak
• the org needs traceability and predictable standards

RSM becomes redundant when:

• the team already has strong DoR/DoD + quality gates
• RSM is implemented as a new phase
• it increases meetings and paperwork
• it slows delivery without improving outcomes

If I had to summarize in one line:

RSM works when it’s a mindset + checklist embedded into existing Scrum flow, not a new process layer.

A Lean Checklist You Can Start Tomorrow

1. Add 3 questions in Refinement:

• What’s the customer value?
• What can go wrong? (risk)
• How do we know it passes? (acceptance criteria + DoD)

2. For high-risk items, require:

• at least 1 happy-path Gherkin scenario
• at least 1 failure scenario
• 1 mitigation bullet for the top risk

3. Improve DoD in Retro:

• one small improvement per sprint (don’t over-engineer it)

Scrum is the vehicle. SQA is the seatbelt. RSM can be your GPS — as long as you don’t stop the car every 5 minutes to stare at the map.

If you want quality to stay consistent, your strongest levers are:

• testable acceptance criteria
• a real Definition of Done
• risk-based thinking (lean, not heavy)
• continuous improvement that people can actually sustain