Timebox – don’t scopebox

Reading time

10 min

In this Play I am looking in more depth at timeboxing. How is the timeboxing approach used in Agile development different from the planning and tracking approaches taught in project management? And why do we choose to timebox in Agile development?

“Timeboxing” is the use of time periods for development which are fixed independent of the progress made. These are widely used in Agile development but timeboxing is often presented as a “given” in Agile approaches. The reason it is important to use timeboxing in controlling complex environments is not always made clear.

The Scrum Guide has little to say on the subject, probably due to its condensed format. It refers to “timeboxing” only in the context of meetings. A Sprint is described instead as “a fixed length event” and there is no clear guidance to why this is the case.

The title quote “Timebox – don’t scopebox” comes from Mary Poppendieck’s book “Leading Software Development”. In her book, she is outlining the approaches of Lean Software, taking the ideas of Lean Manufacturing and applying them to software development. Why then does Poppendieck feel that timeboxing is so important?

Releases

Releases are the main artefacts where we have the options of “timebox” or “scopebox” so let’s start with ensuring we have clarity about what we mean by a release.

Any release is a deployable collection of code changes. This represents an increment in the product, which delivers value to the customer. If we look in the code repository of a typical software company, each code change will be tagged to show which release it belongs to and the collection of code changes is a release.

Releases are deployable software iterations you can package and make available for a wider audience to download and use.
GitHub documentation

But the term “release” is also used for an organisational planning artefact. A “release” is part of a product roadmap and, if we announce it in advance, we have a plan to deliver. At the point when it has been released, it is a clearly defined and tagged set of code changes. However, when the work starts it is more nebulous and we broadly have four options for how we communicate a release in advance:

Say nothing – we tell the customers nothing in advance, and release the code when it is completed.
Fix the features – we tell the customers what value they will get (not the exact code), but not when.
Fix a release date – we tell the customers when they will have new code, but not what code.
Announce features and date – we tell the customers both what and when

An ideal approach for an engineering team would probably be the first of these. Planning ahead distracts from development, and so more coding can be done if we maintain freedom for change. We can then use a “noestimates” approach or deliver continuously.

An ideal solution for a marketing team might look different. Batches of identified features are easier to communicate as incremental value. A clear date allows a marketing campaign. A fixed predetermined set of features makes discussions and commitments to the customer easier.

As a result, teams tend to use something in the middle, either scopeboxing (2), adding some level of time prediction, or timeboxing (3), with some level of feature prediction. Frequently this is without a clear decision on the approach across the organisation. Often the opinion on the approach being used and what has been committed varies radically between groups.

The iron triangle

Project management theory introduces “the iron triangle” of time, effort and scope. This is also called the “triple constraint” and is possibly based on the work of Martin Barnes in the 1960s, although the importance of these parameters was recoginised in the first formularisation of project management in the 1950s.

These are three key parameters which will affect the ability to complete a piece of work. Each of these three operates as a constraint and affects value:

Time – making value available to customers faster will generally benefit the company and the customers
Scope – making more value available to customers will again generally be of benefit
Effort – using less effort will reduce costs and so benefit the company

The “iron triangle” concept identifies that the three are related constraints on a piece of work and that affecting any one of these will need to be balanced by a change in the others. For example, if we wish to deliver work faster, we will typically need to use a higher rate of effort or reduce the scope, or maybe both.

Of course this is just an analogy, not a simple multiplicative relationship. Especially in a complex environment, doubling the team size will not halve the time taken. This has been repeatedly emphasised, most noticeably in Frederick Brooks’ work. However it is a useful analogy to recognise that there are tradeoffs between these parameters.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
“The Mythical Man-Month” – Frederick Brooks

Scopeboxing – the project approach

In a project-based approach, a goal is set and a project is developed to achieve the goal. Given the constraints of the iron triangle, we have an initial scope and then have to balance the other two parameters – time and effort. When creating a project, we pull together a project team of the size and skills to deliver the scope in the desired time.

How big a team do we need? That’s a tough question which a project answers by planning. Taking a reductionist approach, we start with the scope, decompose this into tasks, estimate the effort needed and decide the balance of project team which will deliver the project in an acceptable time.

I’ve worked extensively with project and program teams and it’s not easy to do this well. The basic flow is to start with the scope, decompose and estimate the work, agree the team, build a plan and determine the schedule. There is usually some rework in the planning, adjusting the team and even the details of scope to get an acceptable schedule.

When the project runs, it is usually split into milestones, each with its own agreed scope, and again there is a plan which predicts the schedule based on milestone scope. The scope of the milestone is fixed so tracking involves monitoring progress against the plan, reforecasting and communicating the end date. If there is sufficient variance, we use change control to agree a change to one of the three parameters – team size, end date or (usually as last resort) scope.

We can call this “scopeboxing” (although this is not a widely used term). We build a “box” of a size determined by the scope. We fill it up with work. We predict and track an end date. We start work, and when we have achieved all the scope, we stop.

A scopeboxed project approach relies on understanding scope and making a good prediction of end date before work begins. In some situations this is possible and projects work well in these “complicated” environments. When working in the semiconductor industry my team would predict the delivery date two years ahead. But it would first take a year of the project on planning and specifying before they could get to that point.

Timeboxing – the Agile approach

In a timeboxing approach we fix the time dimension rather than the scope dimension. Where a project has fixed scope milestones leading towards a fixed scope end goal, we instead have fixed date points.

Each one of these points represents an increment – a step along the way. The schedule for each is fixed – we know when we start and finish the next phase of work.

This is well known as the approach taken at the level of iterations or Sprints. Each Sprint is a fixed timebox and ends on a specific date, regardless of the progress which has been made.

As we will see, in Agile development it is valuable to take the same approach to releases – timebox, don’t scopebox.

Why is timeboxing different?

If you are timeboxing you need to start with a different mindset from scopeboxing. This can be a problem because people are typically taught the “project” way of approaching a problem. An inexperienced team using timeboxing might approach the work like a project with a fixed scope.

Commit to a set of work at the start. This could be the scope of an iteration or of a release.
Part way through they realise that the work will not all be completed.
As a result they rush to finish by the end of the timebox.
Quality is impacted and sustainable pace working breaks, leading to both a poor product and a dissatisfied team.

We have all seen this approach fail. So what have they done wrong?

The team are treating the work as a project and still have the “scopebox” mindset of a fixed scope of work. They have tried to add a fixed timeframe to a fixed scope and now they have no degrees of freedom (the iron triangle is called the “triple constraint” for a good reason). The team typically try to adjust effort to compensate with late nights and overwork, but inevitably they are unable to complete the work and quality (and morale) suffers.

An Agile team doesn’t undertake the significant initial planning that scopeboxing needs. It probably has a complex environment where this is not an effective approach. So if the team approach the timebox like a scopebox, they will likely fail.

How to do timeboxing well?

To use timeboxes effectively, teams need to “unlearn” this project approach and think about timeboxing differently. A scopeboxed approach assumes that you will get everything you want – the full scope. But in a complex environment, we cannot predict accurately as knowledge is emergent. So “the full scope” doesn’t even have a clear meaning.

The starting point has to be the assumption of change and learning which is central to Agile development. This is why timeboxes work so well at the iteration level. They enforce a review cadence at every iteration tick. You prioritise, you make progress, you review, you reprioritise. Approach it like the Shewhart (Plan/Do/Study/Act) cycle popularised by Deming. If you scopeboxed an iteration, then a gnarly problem would push out your review point at exactly the time you need it.

The key purpose of timeboxes is to force you to make choices.

It’s not obvious that timeboxes are about choices, but you need to approach them with that mindset. By making the time visible, you have to decide how best to use that time.

Which means you need to ruthlessly prioritise the work, something which is key to effective backlog management. At any point you need to decide what is most important and get it done with minimum distraction. In a Sprint, the Sprint Goal in Scrum tells you what is important and each team member focusses on closing out work to advance the goal.

I’ve always said timeboxes weren’t about time, but about forcing hard decisions.
Jim Highsmith

Good practices

While people generally think about iterations as timeboxes, it is also critical to think about releases in the same way. If timeboxing helps manage progress on short iterations, it also helps keep focus when looking at product roadmaps.

Releases should be timeboxed, not scopeboxed. This means that we set a release date and aim to deliver on that date. Of course, like the naive team described above, we could try to fix both scope and time. This happens surprisingly often. But the iron triangle reminds us that this is a bad idea.

If we timebox the release and genuinely intend to release high quality software on time, we must follow these principles:

Ruthless prioritisation

Ensure that all work for the release is in a priority order. Work on the highest priority items first. As with all backlog, revisit your assumptions and reprioritise if needed. This will ensure that when the end of the timebox occurs you have achieved the greatest value.

Minimise work in progress

Avoid parallel working and make sure that each feature is completed to releasable quality before moving to the next. This again ensures that you have the maximum shippable value when the timebox ends.

Limit commitment

As we have seen, if you promise a large scope to customers you will end up with a scopeboxed release and no capacity to deliver. Commit only to the items at the top of the prioritisation list. You will do these first and so have high confidence level.

Minimise batch size

If your timebox is large, there will be an expectation you commit to substantial amounts of work. Since this work is uncertain, you build up risk. More seriously, anything which is not delivered in the release must wait longer for the next release, which increases the pressure to ship it at low quality. As with iterations, shorter timeboxes for releases allows you to continually review and replan.

The last word goes to the full quote from Mary Poppendieck about how best to timebox releases.

It is very important to defer public commitment to exactly which features will be in the product, because this makes it possible to reliably release the product on time. The release date is guaranteed, but the exact features are not. Timebox—don’t scopebox.
“Leading Software Development” – Mary Poppendieck