Agile and Scrum for QA Engineers: What You Actually Need to Know

In Waterfall, QA reviewed finished work at the end of a months-long cycle. In Scrum, QA is part of the team building the product, which changes when you're involved and what you're responsible for. Acceptance criteria written by the Product Owner become your test cases; sprint planning is where you catch unclear requirements before development starts; and "done" means tests are passing in CI, not just code merged.

Waterfall vs Agile: why it matters

The old way of building software was Waterfall: requirements first, then design, then development, then QA, then release. Each phase completed before the next one started. QA happened at the end, after everything was built.

The problem: by the time QA found a bug, it had been there for months. Fixing it meant going back through architecture decisions that nobody remembered clearly. Releases were risky because large batches of untested changes went out all at once.

Agile is the response to that. Instead of one big release after months of work, you build and ship in small increments, typically two-week cycles. QA is part of each cycle, not a phase after it.

This changes what a QA engineer's job looks like:

• You test features as they're built, not after everything is done
• You're in planning meetings, not just testing meetings
• Your feedback influences design decisions before code is written

The Scrum framework

Agile is a set of values and principles. Scrum is the specific framework most teams use to implement it. When someone says "we work in Agile," they almost always mean Scrum.

Roles

Owns the product backlog: the prioritized list of everything the team will build. The PO decides what gets built and in what order, based on business value. Not a technical role, but needs to understand what users need and explain it clearly enough for developers to build it.

Facilitates the process. Runs ceremonies, removes blockers, protects the team from external interruptions. Not a manager; doesn't assign work. More of a process coach.

Usually 5-9 people: developers, QA engineers, sometimes UX. Cross-functional: the team collectively owns delivery of working software.

In Scrum, QA is part of the development team, not separate from it. You're not "the QA department reviewing the developers' work." You're a team member with a specific skill set contributing to a shared goal.

Artifacts

The full list of features, bug fixes, and technical work the team might do. The PO owns and prioritizes it. Items at the top are the most important and the most detailed. Items at the bottom are vague. They'll get refined when they move closer to the top.

The subset of the product backlog the team commits to completing in one sprint. Created during Sprint Planning.

The standard format for backlog items:

As a [type of user],
I want [some goal],
so that [some reason].

Example:

As a registered user,
I want to filter items by status,
so that I can quickly see only items in progress.

User stories describe intent, not implementation. How you build it is the team's decision.

The specific conditions a story must meet to be considered done. Written by the PO, validated by QA.

Example:

Given I am on the items page
When I select "In Progress" from the status filter
Then only items with status "In Progress" are displayed
Then items with other statuses are not visible
Then the filter selection persists if I refresh the page

These become your test cases. When all acceptance criteria pass, the story is done.

A team agreement on what "done" means. Typically includes: code written, code reviewed, tests written, tests passing, deployed to staging, documentation updated.

QA's contribution to the DoD is usually: automated tests written and passing in CI, manual exploratory testing completed, no open critical/high bugs.

The Sprint cycle

A sprint is a fixed time period, usually two weeks, in which the team builds a set of features. The cycle repeats.

Sprint Planning (start of sprint)

The team selects items from the product backlog for the sprint. Items are broken down into tasks, estimated, and assigned.

• Ask clarifying questions about acceptance criteria
• Identify missing test scenarios the PO hasn't thought of
• Flag items that don't have enough detail to test (send them back for refinement)
• Estimate testing effort. If a story takes 3 days to develop, how long will it take to test?

Daily Standup (every day, ~15 minutes)

Three questions per person:

1. What did I do yesterday?

2. What am I doing today?

3. Do I have any blockers?

Short, focused, no problem-solving. If something needs deeper discussion, it happens after the standup with the relevant people.

• "Yesterday I finished testing the filter feature, found one bug and logged it. Today I'm testing the modal form. No blockers."
• "Yesterday I was blocked because the staging environment was down. Today it's back up, continuing with the upload tests. No blockers now."

Sprint Review (end of sprint)

The team demonstrates completed work to stakeholders: the PO, managers, sometimes customers. Only work that meets the Definition of Done gets shown.

• Confirm what's done and what isn't (partially done doesn't count)
• Sometimes demo the testing scenarios, not just the features
• Flag anything that was completed but has known limitations

Sprint Retrospective (end of sprint)

The team reflects on the process, not the product. What went well? What didn't? What do we change next sprint?

Three categories:

• Keep: things working well
• Stop: things that aren't working
• Start: things we should try

This is where QA often raises process issues: tests are running too slowly in CI, developers are breaking the test environment without warning, stories arrive in the sprint without acceptance criteria.

Between Planning and Review: the sprint itself

A typical QA workflow during a sprint:

Testing in parallel with development, not after, is the core difference from Waterfall.

Bug lifecycle in Scrum

When you find a bug:

1. Log it with clear reproduction steps, expected vs actual behavior, severity

2. Link it to the story it was found in

3. Discuss with the developer. Is it a bug or a misunderstanding of requirements?

4. Prioritize with the PO. Critical bugs block the sprint; minor bugs can go to the backlog

• Critical: blocks core functionality, data loss, security issue. Fix now.
• High: major feature broken, no workaround. Fix this sprint.
• Medium: feature partially broken or workaround exists. Fix next sprint.
• Low: cosmetic issue, minor inconvenience. Goes to backlog.

Key terms you'll hear in a Scrum team

| Term | Meaning |

|---|---|

| Backlog refinement | Regular meeting to review and detail upcoming backlog items |

| Velocity | How many story points a team completes per sprint on average |

| Story points | A relative measure of effort (not hours). 1, 2, 3, 5, 8, 13. |

| Epic | A large feature broken into multiple stories |

| Spike | A time-boxed investigation task (research, proof of concept) |

| Technical debt | Work deferred to keep velocity up, that eventually needs to be paid back |

| Blocker | Something preventing progress, needs immediate attention |

| WIP limit | Maximum number of things in progress at once (prevents context switching) |

Kanban: when you'll see it instead of Scrum

Some teams use Kanban instead of Scrum. The difference: no sprints. Work flows continuously. A board with columns (To Do → In Progress → Testing → Done) tracks state.

QA role in Kanban: pick up stories from "In Progress" when developers mark them ready, move to "Testing," and move to "Done" when they pass. No ceremonies, no fixed cycles. More suitable for maintenance work and bug fixes than feature development.

What interviewers actually ask

Talk about which ceremonies you participated in, what your role was in each, and give a specific example. "I was part of a 2-week sprint team. I attended daily standups, tested stories as they came out of development, and participated in retrospectives. In one sprint I raised the issue that stories were arriving without acceptance criteria and we introduced a refinement step that fixed it."

"I start writing test cases during Sprint Planning, before development starts. That way when a story is marked ready for testing, I'm not starting from scratch. I also test stories as they're completed individually, not as a batch at the end."

"A bug is behavior that diverges from documented acceptance criteria. A missing requirement is behavior not covered by any acceptance criteria. The app is working as specified, but the specification was incomplete. Missing requirements go back to the PO; bugs go back to the developer."