Every Sprint Ships Something

A team is planning a piece of work. The full thing, they estimate, will take three months. Sensibly, they want to cut it down - intending to take a more “iterative” approach - so they propose a smaller version that will take one month.

But this is just a shorter waterfall. Allow me to explain.

The Waterfall in Disguise

You have a big project. You think “big projects are bad”, so you make it smaller. Fewer features, less polish, a reduced scope. But the overall shape is identical: you go away, you build, you come back with the thing.

The one-month version still has a “get the database tables in place” sprint. It still has a “build the backend” sprint. And then it still has a sprint at the end where it finally does something. For most of its life, it delivers nothing.

Making waterfall shorter doesn’t make it iterative. And often scope reduction of this kind hurts both initial and later launches. It’s not the right instinct at all.

The Actual Question

The iterative question is not “how much do we need to ship?” It’s “what’s the crappy version that goes live today and delivers value, that we can make better tomorrow?” It’s not a question of scope, it’s a question of sequencing.

Sometimes that’s a cut-down version of the plan. Sometimes it’s something that isn’t in the plan at all. A spreadsheet. A manual process with an engineer in the loop. A report someone runs by hand. A button that does one thing badly.

Whatever it is, it has to deliver end-to-end value to someone, right now. Not “sets us up to deliver value later” - it actually delivers it. There is no sprint goal that should read “get the tables in place”, because tables can’t deliver value on their own. Nobody’s (and I mean nobody’s) life gets better because of a table schema.

I’ve written about this from the engineer’s side in Learn First, Build Later - intentionally durable, scalable, production code is the most expensive way to learn something. This is the same principle applied to planning. The project is not the thing that delivers the impact. The project is your current best guess about how to deliver that impact. So: what’s the smallest thing we can ship that we are confident will deliver impact, or otherwise will tell us whether the impact is even there?

Software is grown, not built - every layer should earn the next.

Stable Stopping Points

Every sprint should end at a stable stopping point that delivered some value. Keep your eye on the final goal, but take only sprint-sized steps towards it. If you start at the end - get something running end-to-end first, with dummy data / placeholder steps / whatever, and then fill in the gaps - this falls out naturally.

This matters for a reason people underestimate: you can’t assume you’ll get another sprint. Priorities change. Capacity gets pulled. Someone above you decides the thing that mattered last month doesn’t matter this month. If your work is three sprints into a six-sprint plan and none of it is live, you have delivered nothing but tech debt. If each of those three sprints ended with something real in production, you have three real things. And even if they don’t work out, removing three complete things is typically much easier than removing one half-complete thing.

It also changes when you stop. You don’t stop when the plan is complete. You stop when the thing is good enough that it’s more valuable to move on to the next project. That’s often much earlier than the plan said - and that’s a win, not a compromise.

The Spreadsheet Nobody Replaced

A team asks for an internal tool. The “proper” version is months of work - a UI, validation, workflows, permissions. Instead, they ship a spreadsheet and a script: fill in the rows, an engineer runs the script, the job is done.

Everyone agrees it’s a stopgap. Six months later, nobody has asked for the full version. It turns out the spreadsheet was the product. The months of tooling would have been months of waste, and the only way to find that out was to ship the crappy version first.

I’ve seen this happen dozens of times. Don’t assume everything needs to be scalable and durable - even when your users or stakeholders are telling you it needs to be. They might be wrong!

Consolidation Is Part of the Loop

A very common objection to this pattern goes something like: “if we ship a load of small things fast, won’t we end up with a fragmented mess?”

The honest answer is maybe. But that’s a challenge for your engineering, it’s not an argument against shipping. The consolidation steps - the refactor, the shared component, the cleanup - get baked into the iterative process. They’re a sprint goal like any other, and they earn their place by making the next valuable thing cheaper. What they don’t get to do is hold that value hostage.

Don’t Fall Back

Teams that have been burned before are especially prone to slipping back into the big plan. It feels safer. It feels more “professional”. It produces nicer Gantt charts. It lures us back in with a sense that we are finally bringing certainty and order to the chaotic and often unpredictable world around us. It’s a lie.

If someone in a cheap costume with a glowing snow globe presented you a plan and said “this is how your next six months are going to play out” you’d likely roll your eyes and toss it away. But put that person in a t-shirt with an ironic slogan and give them Jira and suddenly we all believe.

Resist the temptation! Don’t try to build “the whole thing”. Don’t try to build “the cut down version”. Don’t get stuck in long prioritisation analysis about which parts of the whole thing to build. Ask what goes live this sprint, make sure it’s something real, and then ship it.

Then ask again in two weeks.