What a sprint is and why it exists

What it is

A fixed-length period — usually one or two weeks — for which a team takes on a defined amount of work and commits to bringing it to a finished state.

The key word is fixed. The length doesn't change. If you don't finish, tasks move, not the end date.

Why it exists

A regular result. Every two weeks there's something to show. That changes how both client and team relate to the work: the project stops being a six-month black box.

Predictability. After several iterations you can see how much the team actually gets through. Planning then becomes more honest.

Points to stop and reflect. The end of an iteration is a natural moment to ask whether you're heading the right way.

A cap on scope. You can't take everything at once: you have to choose what matters.

What happens at the start

Planning. The team looks at the list of work, breaks down the top items, estimates and decides what to take.

Two rules that are frequently broken:

• The team takes it; it isn't assigned to them. People who estimated and agreed themselves work differently from people handed a plan.
• The amount must be achievable. Taking extra "in case we manage" is a reliable way to miss every time and gradually stop believing in plans at all.

What happens at the end

A demonstration. Not a description but a showing of something working. The difference matters: anything can be described.

A review. What got in the way, what to improve, what to agree. It gets its own article, because it's the most useful and most frequently skipped part.

Why scope doesn't change midway

If work can be added at any moment, the iteration loses its point: planning becomes a formality and the team never finishes what it started.

Hence the rule: something urgent appearing midway either waits for the next iteration or enters in exchange for something of equal size. The second by common agreement, not at the request of whoever asked loudest.

One exception: a genuine emergency. Then everything stops and gets fixed.

What to do when you don't finish

Don't extend the iteration. It's the first thing you'll want to do, and it destroys the whole system.

Carry the unfinished work over. Calmly, without drama.

Work out why. Usually one of three: you took too much, the task was harder than expected, or something external interfered.

The first is cured by taking less next time. That isn't defeat but calibration: a team needs several iterations to learn its real pace.

Trying it yourself

On your own project: take two weeks, define the scope, bring it to a working state, show someone, review the outcome.

One such cycle gives understanding that theory can't. And you'll discover what everyone discovers: you took on roughly twice what you finished.