How We Run a Two-Week Sprint

Why two weeks and not one, or four

One-week sprints spend too much of the cycle on ceremony — plan, demo, retrospective — relative to work. Four-week sprints let a misunderstanding run for a month before anyone catches it. Two weeks is long enough to finish something meaningful and short enough that a wrong turn costs a fortnight at most.

It also matches how clients actually work. Most people can commit an hour a fortnight reliably. Very few can commit an hour a week for six months, whatever they say at kick-off.

Monday of week one: planning

We start by agreeing what the sprint will produce, in terms you can verify. “Users can upload a CSV of orders and see which rows failed validation” is a sprint goal. “Work on the import module” is not.

The backlog for that sprint gets fixed at that point. Anything new that arrives during the two weeks goes into the next sprint unless it is genuinely urgent, and urgent has a definition: production is broken, or a legal or commercial deadline is at risk.

A sprint that changes shape halfway through is not agile, it is just unplanned work with a nicer name.

Tuesdays and Thursdays: the written update

Two short written updates a week, in the shared channel. Each has the same three headings, deliberately:

1. Moved — what is now working that was not on the last update
2. Blocked — anything stopped, and what would unblock it
3. Needed from you — decisions or access, with the date after which it delays the sprint

That third heading is the one that keeps projects on time. A decision that would have blocked us in week five gets flagged in week two with a deadline attached.

Friday of week two: the demo

Thirty to forty-five minutes on a call, always against a live staging URL, never a slide. We walk the sprint goal, then hand over and let you click it yourself. Bugs found in a demo are logged live and fixed in the next sprint.

If you cannot attend, we record it and send the link with a written summary. What we do not do is skip it — a sprint with no demo has no verifiable outcome, and two of those in a row is how projects quietly drift.

Where change requests fit

Between sprints. At the demo you can add, remove or reorder anything for the next sprint. If the change is within the agreed scope it costs nothing. If it expands the scope we price it before the next planning session and you decide.

• Reordering priorities — free, any time between sprints
• Swapping one feature for another of similar size — free
• Adding scope — priced in writing, approved before work starts
• Design tweaks inside an agreed screen — free, within reason

What we do in the last sprint

The final sprint of a build is deliberately lighter on new features. It is for the things that decide whether launch goes well: load testing, error handling on the unhappy paths, the handover documentation, and a rehearsal of the actual deployment.

Teams that fill the last sprint with features launch on a Friday and spend the weekend firefighting. We would rather ship one fewer feature and have a boring Monday.

Frequently asked questions