How I run 1-2 week sprints with demos

Clients don't trust process descriptions - they trust seeing working software. The sprint format I use is built around that: short cycles, a demo at the end of every one, and scope that's fixed for the sprint, not for the project.

I've run projects this way for years - solo engagements and teams of six - and it's the single format that has never produced a "why isn't it done yet" escalation. Not because it's clever, but because it removes the places where those conversations hide.

The shape of a sprint

• 1-2 weeks. One week when the client wants fast feedback and the work is exploratory; two when the tasks are bigger and need focus. Longer than two and the feedback loop rots - by week three nobody remembers what was agreed.
• Fixed scope, agreed upfront. At sprint start we agree on a list of deliverables. Mid-sprint requests go to the backlog, not into the sprint. This single rule kills 90% of "why isn't it done yet" conversations - there's a written list, and either the thing is on it or it isn't.
• Demo, not report. At the end - 30 minutes, screen sharing, clicking through what actually works. No slides. If it can't be demoed, it doesn't count as done. Infrastructure work gets demoed too: show the dashboard, the deploy pipeline, the alert firing in a staging environment.

Why the demo matters more than the sprint

A demo is a forcing function. It's impossible to hide a half-finished feature behind status jargon when the client is watching the screen. "90% done" dies the moment someone clicks the button and nothing happens - and that's exactly the honesty that keeps projects healthy.

It also surfaces misunderstandings at week one instead of month three, when changing course is still cheap. I once demoed an admin panel where the client immediately said "no - approvals should go the other direction". Twenty minutes of rework. Without the demo, that's a month of building the wrong thing.

And honestly: demos build trust faster than any status report. A client who has seen five consecutive demos where "done" meant working stops asking for daily updates. The report becomes the demo; the trust becomes the process.

Estimates: honest ranges, not single numbers

I estimate in ranges and per-sprint, never as one grand number for the project. "This sprint: 6-8 days of work" is honest; "the whole thing will take 3 months" is a guess wearing a suit.

Ranges also make scope conversations concrete. If the client adds a feature mid-sprint, we can literally see what it pushes out: "that's 2-3 days; it replaces item 3 or we extend the sprint". No drama, no hidden overtime - just arithmetic on a shared list.

The discipline that makes ranges work: when a sprint comes in above the range two times in a row, I stop and re-estimate the remaining work instead of quietly absorbing the overrun. Absorbing overruns is how "6-8 days" silently becomes 12, and how trust dies.

What breaks this format

• A client who can't attend demos. Record them. A five-minute Loom with the sprint's deliverables clicked through keeps the loop closed even across time zones. What kills the format isn't absence - it's silence about absence.
• Pure discovery work. Some sprints are spikes: "figure out if this API can do X". Fixed scope doesn't apply; timebox instead. "Two days of research, written conclusion either way" is a deliverable you can demo - the deliverable is the conclusion.
• Fixed-price contracts. Sprints still work, but the scope conversation changes: the price buys a backlog, not a feeling. Every added item is a change order. If that framing scares the client, the contract was the problem, not the process.

The first sprint is different

The first sprint of any project has a special job: it's not primarily about features - it's about establishing that the format works. I deliberately front-load something demoable into it, even if it's small: a walking skeleton of the app, a deploy pipeline that puts a stub page on production, a data model with one real screen on top of it.

That first demo does three things at once. It proves the delivery loop works (code → production → something the client can click). It surfaces environment and access problems while the sprint is still cheap - nothing is more demoralizing than discovering on day nine that the client's SSO doesn't work the way the docs said. And it gives the client their first taste of the rhythm: here's the thing, it's real, next one comes in a week.

What I explicitly don't put in the first sprint: the hardest technical risk. Tempting as it is to "get the scary part done early", a first sprint that ends in "the spike failed, we're pivoting" - even when it's the right engineering call - reads as failure to a client who has just learned to trust demos. Risky spikes go into sprint two, once the rhythm exists to absorb them.

What this looks like in practice

A typical week: Monday - sprint planning, 30 minutes, agree the list. Through the week - short async updates in the tracker, no meetings unless something is blocked. End of week - demo, feedback, next sprint's scope. The whole ceremony overhead is about 90 minutes per sprint.

The result I'm optimizing for isn't velocity - it's predictability. The client knows what will be demoed on Friday, and it is. That reliability is worth more than raw speed: a predictable team gets forgiven an occasional slow sprint, while an unpredictable fast one gets replaced the first time it slips.

← All posts