Testing Within Sprints — Planning, Execution, and Demos

The most common cause of missed sprints in agile teams is the same in every company: developers finish features on day 8 of a 10-day sprint, leaving 48 hours for "testing." Predictably, two days is not enough — bugs are found, fixes are pushed, and either the team blows the demo or the team passes work that should not have passed. This is waterfall within a sprint, and it is a failure mode every tester needs to recognise on sight. The fix is to make testing continuous across the sprint instead of compressed at the end.

The bottleneck pattern

The bad pattern unfolds the same way every sprint. Days 1–2: planning and refinement; developers start coding; tester writes a few cases but is mostly idle. Days 3–7: developers code in parallel; testing has not really started because nothing is dev-complete enough to test end-to-end. Day 8: five stories drop "dev-complete" within hours of each other; the tester now has 30+ test cases plus exploratory plus regression in two days. Days 9–10: testing finds critical bugs, developers context-switch to fix, fixes need re-testing, some bugs get deferred to make the demo. Demo happens with known issues; retro apologises. The pattern repeats forever unless the team explicitly breaks it.

Two ways a sprint can run

The diagram below shows the same sprint executed two ways — one as the bottleneck pattern above, one as continuous testing — and exactly how each one feels by day 10.

The two versions look superficially similar — same stories, same team, same calendar — and yet feel completely different to live through. The structural difference is just when testing starts.

Shift-left in practice

The principle behind continuous testing is shift-left: start testing-related activities as early in the sprint as possible. Concretely, that means:

• Test cases are written during, not after, development. As soon as the story is dev-ready and the developer has started coding, the tester is already writing the cases that will run against it. By the time the story drops "dev-complete," the cases are queued.
• Refinement reviews include the tester. Ambiguity caught at refinement costs nothing; ambiguity caught at testing costs a re-implementation. The tester's questions during refinement are some of the highest-leverage work in the sprint.
• Exploratory testing on partial features. A feature that is 70% built can still be tested for the parts that work. You will catch bugs in those parts before the developer finishes, and the developer can fix them while the surrounding code is still fresh.

Testing in slices, not all at once

A practical rule: as soon as a single story is dev-complete, test that story end-to-end the same day. Do not wait for the rest of the sprint to drop. The benefits compound:

• Bugs are found while the developer remembers what they wrote.
• Tests run in parallel with continuing dev work, so the team's overall throughput is higher.
• The sprint never has a "test everything in 48 hours" cliff.
• By day 9, the team is running risk-based regression rather than firefighting open bugs.

The cost: more context-switching between stories. The benefit so dramatically outweighs the cost that no team that adopts the slice-testing pattern goes back to the bottleneck pattern voluntarily.

Regression strategy in agile

You cannot run a full manual regression suite every sprint — there is not enough time. The pragmatic approach uses risk-based testing (covered in chapter 1):

• Always re-test the areas this sprint touched. Code change is the strongest predictor of regression risk.
• Always re-test the high-impact areas regardless of changes. Login, checkout, billing, password reset — the flows that matter most should be smoke-tested every sprint, even when no code changed near them.
• Rotate the rest. Lower-risk features can be smoke-tested every other sprint, or quarterly, with explicit acknowledgement in the test plan.

This buys most of the safety with a fraction of the time a full regression would consume.

Demo prep

The sprint demo is part of the testing flow, not an afterthought. The tester's contribution:

• Decide what to demo and what to skip. Anything still in flux should not be on stage in front of stakeholders.
• Walk the demo path beforehand on the demo environment. Twenty minutes of pre-demo testing prevents the most embarrassing kind of bug — the one a stakeholder finds before the team did.
• Be ready to talk about residual risk transparently. "We tested everything in scope; here are the two known limitations we are tracking" is a stronger position than pretending a release is bug-free.

A demo run by a team that has practised it the day before is dramatically more confident than one improvised on the day.

⚠️ Common mistakes

• Letting work queue to day 8. The single most expensive mistake in agile testing. If a story is dev-complete on day 5, test it on day 5.
• Writing test cases only after dev is done. Test design is a parallel activity, not a sequential one. Start as soon as the acceptance criteria are stable.
• Demoing untested features. A demo of a feature you have not personally walked through end-to-end will eventually go wrong on stage, in front of the worst possible audience. Always run the demo path in the demo environment first.

🎯 Practice task

Spend 25 minutes diagnosing your team's sprint pattern.

1. Look at your last completed sprint. Map out which day each story became dev-complete and which day testing finished on it.
2. Calculate the percentage of testing time that fell in days 1–6 versus days 7–10. If more than half is in days 7–10, you have a bottleneck pattern.
3. Identify one specific change that would have moved testing earlier — was a story ready earlier than it was picked up? Were test cases not ready in time? Was there an environment delay?
4. Bring the data to your next retrospective. Specific numbers — "70% of testing was in the last 30% of the sprint" — make far stronger retros than vague feelings, and tend to produce real process changes.