Mini-waterfall: when the Sprint is just phases in a box

A team adopts two-week Sprints and keeps its old way of working inside them. In week one the analysts clarify the stories. Early in week two the developers build. The last two days belong to the testers. The Sprint ends on a Friday and the testers are still finding defects. A story is carried over, and then another. The ritual is Scrum, and the flow is waterfall in a smaller box.

What it looks like

On the board the pattern is easy to read. Cards sit in analysis for the first days, move to development at the middle and gather in test at the end. The "test" column is empty on day six and overflowing on day nine. Burndown is flat for a week and then drops, or does not drop. The Daily Scrum is a status report of which phase each item is in.

The waterfall model arranges work in distinct phases, each completed before the next begins, with each phase's output feeding the next. Its known weaknesses include that testing happens only at the end and that late discovery of problems forces rework. A mini-waterfall inherits both, on a smaller scale. The problems are the same, only compressed: a defect found on day nine has one day to be fixed, not the weeks that a long project might allow, and so the pressure is higher.

What the Guide says

The Guide describes a different shape. In a Sprint, all the work needed to achieve the Product Goal, including planning, building and review, happens within the Sprint. Each Sprint may be considered a short project, the Guide says, and it is a short project in which the team turns selected items into a usable Increment. The Developers plan the work in tasks of a day or less and adapt their plan daily toward the Sprint Goal. The Definition of Done is the standard, and the Increment is born the moment an item meets it. Nothing in the Guide assigns activities to parts of the Sprint. The Guide describes a team that holds all the skills and works on the items together.

A mini-waterfall is therefore a pattern in how the team uses the Sprint. It does not break a rule of the framework in an obvious way. It breaks the logic of the framework, which is to get to a verified piece of the product early and often.

Why it forms

Specialists. Analysts, developers and testers are organised as separate groups, even if in one team. Work passes from one to the next.

Large stories. A story that takes the whole Sprint cannot be passed through stages quickly. It has to move as a block.

Old habits. People are used to phases and to a handover with a document.

Test environments and data that are available late.

Fear of wasted work. Testing before the code is "finished" feels premature.

The Definition of Done. If testing is not part of it, testing slips later and later.

Manager expectations. A plan with phases is easy to report on.

Why it hurts

• Delay in feedback. The developer who wrote the code on Tuesday hears of the defect on Friday and has to reload the context.
• Defects found too late to fix well. Pressure leads to patches.
• Carry-over. Stories that fail in test roll into the next Sprint, which then starts with leftovers.
• Idle time. Testers wait early, developers wait late.
• Weak Definition of Done. Under pressure, "done" becomes "mostly tested".
• No usable Increment. The Guide requires the Increment to be usable and verified. In a mini-waterfall this arrives at the last minute or never.
• Poor forecasting. Throughput swings, because everything finishes in the last two days or not at all.
• Loss of the Sprint Goal. The goal only becomes clear at the end, when it is missed.

How to fix it

1. Slice thinly. The root cause is usually large stories. A story that takes a day or two can pass through all the skills in a Sprint's first days. See splitting user stories. Aim for most stories being done within three days.

2. Test as you build. Testing does not wait for the code. Write acceptance examples before building, and test each small piece as it is made. See test-driven development and automated testing and the Definition of Done.

3. Work on fewer things at once. Limit work in progress so that items flow to done early. See WIP limits in Scrum.

4. Swarm. When an item is waiting, the whole team helps it through, including testers pairing with developers. See swarming.

5. Put the whole path in the Definition of Done. Testing, review and deployment are inside it, so that "done" means the whole path.

6. Prepare environments and data. Make test environments available from day one.

7. Make cross-skilling a goal. If developers can test and testers can code a little, bottlenecks ease. See T-shaped skills.

8. Look at the board for flow, not phases. The Daily Scrum asks what would finish the oldest item today.

9. Show done work early. The first finished story on day three beats five stories finished on day ten.

A worked example

This is an illustrative team of six with two testers. Its two-week Sprints have followed the pattern for a year. Typical week: four stories analysed on Monday, developers busy Tuesday to Thursday, testing from Friday into the next week.

In a Retrospective, the team looks at its board history. Of eight stories in the last Sprint, six entered "test" on the final two days. Three failed, and two of those were carried over. The testers had been idle for three days earlier in the Sprint.

They try three changes. Stories are sliced so each is expected to take under three days, which makes twelve stories a Sprint, not eight. A tester joins each story at the start to write the acceptance examples. And the team agrees that nobody starts a new story while two are waiting for test. In the first Sprint, the first story is done on day three, tested the same day. By day eight, nine stories are done and tested. The last two days are used for the remaining three, with the whole team on them. Nothing is carried over.

The total effort did not change. The shape of the work did, and the defects were found while the code was fresh.

Cautions

• Fixing it by lengthening the Sprint. A longer box makes it worse.
• Blaming the testers. The pattern is in the way the work flows.
• Adding a "test Sprint". It repeats the waterfall at a larger scale.
• Splitting by layer instead of slicing vertically.
• Skipping the conversation with the team about why it happens.

How to practise it

Look at your board's history for the last Sprint and note on which day each story entered test. If most did so in the last two days, pick the thinnest slice you can and test it on day two. In the simulator the Developer role shows how task order and testing within a Sprint affect what is Done at the Review.