4. Planning and monitoring the sprint

Your backlog is in order, the roles are assigned and the sprint can begin. Now the question that trips things up in practice: how much work do you take on, and how do you know halfway through whether you are going to make it? Agile has three answers to that, all three of which go against your gut feeling. The time is fixed instead of the amount of work, you estimate in points instead of hours, and you measure your team's pace afterwards instead of promising it in advance.

Timeboxing

Timeboxing is the most characteristic planning principle of agile. You set aside a fixed period in advance, the timebox, in which an amount of work is taken on. That period is fixed. What fits into it and what the outcome is may vary, but the end date does not move.

That is exactly the inverted triangle from chapter 1, but as a planning instrument. In traditional project management you fix the scope and let the time flex. With timeboxing the time is fixed and the scope adapts.

You apply it at four levels, each nested within the next. At project level the entire project is given a fixed end date, four months for example. At release level each interim delivery gets its own timebox, six weeks for example. At sprint level each sprint is a timebox of one to four weeks, usually two. And at day level even the Daily Stand-up is timeboxed, at exactly fifteen minutes.

The ground rules of a timebox

A timebox is more than a deadline. Five rules give the instrument its strength. The end date is fixed and does not move. The scope is flexible: whatever is not finished goes into a subsequent timebox. At the end there is always a working result. The team works self-directed within the timebox. And the work is done on the basis of priority, not in order of arrival.

That last rule is the reason chapter 3 was about MoSCoW. You always start with the Must haves, so that what is left over is also the work you can do without. If a sprint gets out of hand, you cut work instead of stretching the deadline. That feels awkward at first, but it is exactly what gives agile its grip: you keep time and budget under control and always deliver something that works.

Release planning

Before the sprints begin, you draw up a release plan: a high-level overview of which functionality will be delivered in which release, spread across successive sprints. A release might consist of four two-week sprints, together eight weeks of work with a working delivery for the user at the end.

You don't plan in detail who does what; you provide direction and sequence. A release plan gives stakeholders a realistic picture of what they can expect and when. It isn't a promise set in stone, but a signpost that you adjust each sprint.

Story points and Planning Poker

Instead of hours or days, you estimate in story points. A story point expresses how large, complex or risky a story is compared with other stories. A story of 2 points is roughly twice as large as a story of 1 point. Whether that amounts to one day or three in hours is beside the point at that moment. That sounds vague, but it works better than estimating in hours, because people are far better at comparing than at predicting.

Planning Poker is the best-known technique for assigning those points. Each team member gets a set of cards with the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. The Product Owner reads out a story, the team asks clarifying questions, and then everyone picks a card at the same time. That simultaneity is the whole point: it means the first or the loudest voice doesn't determine the estimate. If the numbers differ widely, the highest and lowest estimators explain their choice and you estimate again.

Velocity

Velocity is the number of story points a team completes on average per sprint. After three or four sprints you see a pattern. If your team delivers an average of 28 points per sprint, you know that you can select roughly 28 points from the backlog for the next sprint. Not a promise, but a realistic expectation, and a sound defence against a client who would like to cram in 40.

Velocity is emphatically a team measure. You do not compare team A's velocity with team B's, because their points do not mean the same thing. A team at 60 is not twice as productive as a team at 30; they have simply chosen a different unit. As soon as someone starts using velocity to compare teams or to apply pressure, the estimates go up and the instrument is broken.

The scrum board

What you cannot see, you cannot steer. A scrum board shows at a glance where the team stands. At its most basic, three columns: To Do, Doing and Done. Every story or task hangs as a card in the appropriate column, and when a task moves on, you literally or digitally move the card. Many teams add columns such as "In review" or "Test". The principle stays the same: the work is visible, the bottlenecks are visible, and nobody has to ask who is working on what.

Put the board in a place the team passes at least once a day. A board hanging in a closed room, or buried three clicks deep in a digital tool, loses its signalling function. Visibility is half the effect.

The burndown chart

The burndown chart shows how much work is left and how quickly it is decreasing. The horizontal axis shows the sprint days, the vertical axis the remaining number of story points. A straight line from top left to bottom right indicates the ideal progress: if you completed the work evenly, you would follow that line.

The actual line almost never runs exactly along it, and that is a good thing. If it does above the ideal line, more work is left outstanding than planned and you are behind schedule. If it runs below that, the team is ahead of schedule. And a flat stretch on a working day is the signal to watch for: nothing was completed that day, so something has got stuck somewhere. Usually that is one oversized story that three people are waiting on.

This turns the chart into an early warning system rather than an after-the-fact accountability document. If you see on day four that the line is flat, you still have six days to do something about it. If you only spot it in the Review, all you can do is explain why it is not finished.

Summary

• Timeboxing means that the time is fixed and the scope flexes; the end date never moves.
• Four levels: project (four months for example), release (six weeks for example), sprint (one to four weeks) and the Daily Stand-up (fifteen minutes).
• If a sprint gets out of hand, you cut work instead of stretching the deadline; the work that is cut goes back to the Product Backlog.
• A release plan sets out in broad terms which functionality will be delivered when, and you adjust it each sprint.
• Story points express relative size, not hours. Planning Poker with the Fibonacci sequence 1, 2, 3, 5, 8, 13, 20, 40, 100 prevents a single voice from determining the estimate.
• Velocity is the average number of points per sprint for this team, and is not suitable for comparing teams.
• The scrum board (To Do, Doing, Done) shows the status of the work; the burndown chart shows whether you are on track, where a flat section means that something has got stuck.