How *Not* to Do Timeboxing in Agile

Timeboxing can be seen as a core discipline that agile practitioners ought to master. Scrum has five events, for example, each of which can take no more than a maximum amount of time.

Assuming a one-month Sprint — which is itself a timeboxed container for the other events — Sprint Planning can take no longer than 8 hours, the Sprint Review 4 hours, and the Sprint Retrospective would have to be done and dusted in 3 hours. Each Daily Scrum is timeboxed to a maximum of 15 minutes, regardless of the length of a Sprint.

Every one of these events is an opportunity to inspect and adapt something, whether it be a plan of work or an increment of functionality lined up for delivery.

Teams that operate on the basis of continuous flow, and do not “Sprint” at all, generally still find it useful to timebox. Few Kanban teams would accept a daily huddle that dragged on without limit, for example.

The essential constraint is that meetings of any sort tend to be subject to the law of diminishing returns. If a daily huddle were to last 30 minutes rather than 15, it is unlikely to be twice as effective. Breaking timebox limits does not usually improve the quality of an activity. It is typically better to get on with the work, deliver value in a timely manner, and learn from actual experience.

You may also like:  Meetings [Comic]

When the bounds of a timebox are not observed, the focus one might expect from a time-limited activity becomes dissipated. The goal of the activity is no longer kept to the forefront of people’s minds and the effort becomes subject to drift and delay.

Moreover, the ability to compare certain activities can become harder if the time spent on them varies, hence why Sprints ought to be of the same length if their effectiveness is to be compared and contrasted.

Yet, while it can sound as though respecting timeboxes ought to be a “no-brainer” and violations are a rare occurrence, in fact the pressure is often on for teams to break the limits. The antipattern of “unbounded timebox” is rather more common than you might think.

For example, teams may be tempted to extend a Sprint if they think it will increase the chances of their Sprint Goal being met. Doing so will create the illusion of having had a successful Sprint even though the forecast of work was not provided in a timely fashion.

The antipattern of “unbounded timeboxing” tends to arise when product ownership is inadequate, and the pull exerted for delivery is too weak to make disciplined timeboxing seem worthwhile.

Unbounded Timebox is Antipattern of the Month at agilepatterns.org

Unbounded Timebox

Intent: Allow an indeterminate amount of time for the completion of a task

Proverbs: To protract a great design is often to ruin it; Procrastination is the art of keeping up with yesterday

Motivation: The time-boxing of incremental delivery requires the specification of intermediate goals. Time-boxes should be of the same length so that progress can be assessed regularly on a goal-by-goal basis. However, teams can be tempted to try and extend an available time-box if, in so doing, it increases the chances of an intermediate goal being met. The team can then create the illusion of success even though the deliveries that were forecast have not been made.

Structure: A team plans to action certain items from an ordered backlog, and to do so within a time-boxed project iteration. However, inspection of the time-box shows that the goal is unlikely to be met. The time-box is then revised to be of indeterminate length such that it will only complete once the intended goal has been completed.

Applicability: All agile methods, including Scrum, DSDM, and XP, mandate that time-boxes be of a fixed length. They cannot be extended. Any project in which time-boxes have become unbounded is not being run in an agile manner.

Consequences: When a time-box is unbounded, the ability to inspect and adapt the delivery process is compromised. Reviews, retrospectives, and future planning sessions will be deferred until an arbitrary point when the time-box completes. Useful and comparable metrics will no longer be produced iteration by iteration. Progress towards the completion of a project can no longer be gauged in such conditions and risks will be difficult to assess. Incremental deliveries will not occur as forecast, and an early return on investment will not be possible.

Implementation: Unbounded time-boxes tend to occur when product ownership is weak and insufficient pull is being exerted upon a team and their backlog for the regular delivery of valuable increments.

See Also: Iteration

Further reading

Time Box to Scope Box