What is timeboxing?

Timeboxing is the practice of managing based on a fixed schedule.

The ultimate aim of Agile is to deliver everything, of course. But that doesn’t mean that paying equal attention to everything is the best use of the team’s time. That is why timeboxing was invented.

Timeboxing sets rigorous time limits, so that the most important items are driven to the top of the agenda, and the value of other items is actively challenged.

The Iron Triangle

The Iron TriangleTimeboxing can be explained in terms of the so-called ‘Iron Triangle’. Traditional waterfall methods prefer to deliver everything, even if it does mean adding time & cost. That is, functionality takes precedence over budget & schedule.

Agile always prefers delivering on time & on budget. Functionality will be delayed to make sure this happens.

NB: Cost is effectively fixed by time – the team size is usually the major variable cost.

What should be timeboxed?

Any element of Agile can be timeboxed.

  • The delivery schedule is always timeboxed.
    • Individual iterations.
    • Complete releases.
  • But almost anything else can – and should – be timeboxed. For example:
    • Meetings.
    • Planning sessions.
    • Iteration 0.
    • Testing.
    • Showcases.
    • Retrospectives.
    • Etc.

And so should anything else to which the Pareto Principle applies – 80% of the value comes from 20% of the activity.

In each case, timeboxing an activity encourages the team to focus on the most valuable items.

Why timebox?

Timeboxing is based on a simple principle: It’s better to deliver 80% now than 100% never.

  • Traditional delivery methodologies have an unhappy track record:
    • Typically a large fraction of the agreed scope is never delivered.
    • Or delivered massively over schedule & over budget.
      • Only 16% of projects are delivered on budget & on time…
      • … and only 9% is larger companies.*
      • And this is typically after being descoped by 50% or more.
    • And much of the ‘required’ functionality is never used.
  • When a project is running late, adding time is unlikely to work:
    • It does nothing to eliminate the causes of delay.
      • Poor requirements, weak planning, uncontrolled change, uncontrolled risks, counter-productive politics & culture, etc.
    • It encourages other bad practices.
      • Adding resources, increased hours, ‘death marches’, etc.
    • And the evidence suggests that it does not, in fact, work.

In other words, delaying delivery is not a healthy practice.

* Source: Chaos Report 2014. Standish Group.

The three goals of timeboxing

Timeboxing serves many purposes, but the key benefits are simple:

  • Timeboxing ensures that delivery really happens.
  • Timeboxing helps the team to manage risky relationships between time & scope.
    • If we extend the schedule when we are late:
      • The value of what we have already completed is still not realised – 80% now is better than 100% ‘one day’.
      • The historical evidence suggests that it is quite likely that we may never be 100% ready.
    • So we deliver what we have completed.
    • And re-evaluate what we haven’t.
      • Is it really worth the extra effort?
      • Wouldn’t getting on with the next iteration of high-value stories be a better idea?
  • Timeboxing constrains the team to focus on the most value-adding items & tasks.
    • Because there is always limited time, if team members want to do or discuss something, they need to deal with higher priority issues decisively.
      • I.e., not waste time on trivial issues.
    • If a team member wants to raise a lower-priority item, they need to demonstrate its importance.

All three are variants on the basic business case for Agile:

Agile Value Model

What is the Agile alternative?

The Agile approach can be simply summarised:

  • Delivery of working product is the ultimate test of what we have achieved.
    • Timeboxing – delivering strictly on time – helps teams to focus on achieving this.
  • The team always focuses on the most valuable items.
    • Stories, tasks, problems, opportunities…
    • So even partial delivery maximises delivered value.
  • We make quick, highly focused decisions about what is still worth delivering.
    • We expect this to change as the iteration & release progress.
  • What we have already completed has been explicitly confirmed as value-adding by an empowered user.

Rules of timeboxing

Timeboxing is based on a few very simple rules:

  • Deadlines are never allowed to slip.
    • When the time is up, you deliver what you have actually completed.
    • As soon as you can predict that you will not deliver on time, reprioritise.
  • Resources are not added.
    • This only adds complexity…
    • … and makes further delay more likely.
    • See Fred Brooks’ essay ‘The Mythical Man Month’.
  • Quality is never compromised.
    • Only items that meet the team’s Definition of Done fully are delivered.
  • Review the backlog.
    • To check whether undelivered items are still worth implementing.

Timeboxing strategies

Standard definitions of an iteration (or a sprint) give little guidance on how to use the time.

And in most circumstances that’s fine. But if you do need a strategy, timebox models provide one.

There a several major models of timeboxing:

  • The ‘standard’ Agile model.
  • Risk-led development.
  • Dependency-led development.
  • 50-90-100.

All these models overlap to some extent – typically by minimising risk and/or maximising value.

The standard Agile approach

A well-defined backlog should not need a special ‘strategy’ to manage the timebox. And that’s what ‘vanilla’ Agile assumes:

  • Stories are well-defined.
    • That is, they are: Independent, Negotiable, Valuable, Estimatable, Small, & Testable.
    • I.e., they meet the INVEST criteria.
  • Such stories can be implemented:
    • In a single pass/in their entirety.
    • Without worrying about the order in which they are implemented.
  • They are simply implemented in order of stakeholder value.

In such circumstances, the small scale and intensive team collaboration of Agile mean that no special approach to managing the timebox is needed.

Unfortunately, not all Agile teams are quite so fortunate, and often a more sophisticated approach needs to be adopted.

Dependency-led development

Timebox Strategy - Dependency-LedIn Agile, dependencies are always minimised. But that does not mean that they can be completely avoided. And if there are dependencies between stories, this fact should also be recognised.

Dependencies can exist between stories for many reasons:

  • Parts of a single epic.
  • Architecture stories needed before functional stories.
  • Simple functionality before complex options, etc.
  • Testing dependencies.
  • Etc.

This suggests that the team should review the backlog and work out the optimum order for implementing the stories to which they are committed. One method for doing this is to draw up a tree diagram as shown here, which shows the ‘critical path’ linking stories to one another. (The flow of stories is from left to right.)

As the diagram shows:

  • In this case, none of the unimplemented stories stands on the ‘critical path’ (i.e., prevents the value of previously implemented stories from being passed on), so the value of the overall package of stories should not be seriously reduced by failure to deliver them.
  • However, if unimplemented stories were blocking stories that had already been implemented, not only would they prevent the value of the implemented stories from being delivered, but the effort put into those stories would have been wasted.

Click for more on Dependency Management.

Risk-led development

Where there are risky stories this fact needs to be recognised. So this timebox model prioritises high-risk items.

The risk-led approach is simple:

  • The most risky stories are started first.
    • The most complex.
    • The most innovative.
    • The most critical.
  • If they create problems:
    • Either additional effort can be diverted to them before they undermine the whole iteration.
    • Or they can be descoped early, and other stories prioritised.
  • So you still optimise your chances of delivering the most value.

NB: Wherever possible, high-risk stories should be excluded from the current backlog. They are likely to prevent any significant delivery from the current work.


Timebox Strategy - 50-90-100The 50-90-100 strategy develops each story through 3 timeboxes:

  • Timebox 1 – Core
    • Critical items.
    • Basic functionality.
    • High-risk designs.
    • Interfaces & resources.
  • Timebox 2 – Refine
    • Complete functionality & controls.
    • Infrastructure.
  • Timebox 3 – Consolidate
    • Complete cosmetics, branding, etc.
    • Final tweaks & adjustments.

How the stories as a whole are managed depends on the team’s perception of priorities and how quickly the risks and dependencies between individual stories are being dealt with.

Issues & risks

Timeboxing has its complications, of course.

  1. You need to prepare well. Otherwise:
    • The wrong people will be present at your timebox planning meeting.
    • The event will be fragmented.
    • The pace will be slow.
    • The event’s aims will not be achieved.
    • Participants will be distracted & discouraged.
  2. Avoid factors that encourage events to go on too long.
    • Over-commitment, remote locations, formal presentations.
    • Coffee & biscuits.
  3. Strong & noisy individuals can drive the agenda.
    • So risks can be increased.
    • And the most valuable items can be neglected.
  4. You don’t need to treat timeboxes as rigid. However…
    • If you expand them, make sure it’s for genuine emergencies only.
    • If you find that the end of each event is starting to focus on trivia, make it shorter.
      • Story-telling, socialising, irrelevant topics, etc.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?