Unbounded Timebox

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