Use Timeboxes for Scheduling Software Delivery

By Scott Sehlhorst June 20, 2007

Product or project management?

When we hear scheduling, we immediately think project management. But when someone says planning, we hear product management. If you’ve heard of timeboxes, you’re probably thinking of project management—so why have an article in productmarketing.com?

Product management is strategic. Project management is tactical. Both disciplines deal with schedules, plans and releases. As product managers, we need to communicate a release schedule to our stakeholders. We need to build return-on-investment (ROI) forecasts based upon what we deliver and when we deliver it.

Timeboxing is a technique for organizing software delivery—and it can be used for planning or scheduling. In this article, we talk about applying timeboxing as a planning tool, but the techniques also apply to scheduling.

Planning belongs to the product manager, but creating a plan requires collaboration between the product manager and the project manager. Stakeholders have inputs in the form of prioritization.

Timeboxing is a fantastically effective approach to managing that planning process.

Benefits of incremental development

Incremental development is rapidly becoming the standard way to deliver software. Incremental “development” is not the same as incremental “delivery.”

Incremental delivery is, by definition, making partial deliveries of the software throughout the development process (as opposed to waiting until the end of the project to deliver the complete solution).

Incremental development is the process of breaking down the delivery of the complete solution into manageable chunks. A team could use incremental development to “build” the software repeatedly throughout the process, without ever delivering the software to the customers.

Agilists and barrel-riders (over the waterfall) are still debating about the benefits of incremental delivery. Barrel-riders may say “not for this project” about incremental delivery, while agilists are likely to say “not for any project” about waterfall delivery.

Incremental delivery requires incremental development. A waterfall process can still benefit from incremental development. While an incremental delivery process is required to get the massive benefits of early customer feedback, either approach will get the following benefits from incremental development:

  • Earlier insight into delays and problems—allowing adaptation of the plan and schedule
  • Better risk identification and mitigation—early knowledge allows for more effective solutions
  • Greater clarity about project status—at each delivery milestone we know the status of that delivery, instead of compounding delays until the end

What is a timebox?

A timebox is a fixed unit of development capacity. An easy way to visualize a timebox is as a two-dimensional graph. Along the vertical axis is the cost of the development team (per unit time). Along the horizontal axis is time. The longer the iteration is, the wider the timebox becomes.

fixed capacity

The important thing to notice is that with Cost and Time fixed, the capacity of the timebox is fixed. There is only so much that can be accomplished with a given team and a given amount of time.

Note the similarities between this representation and the venerable iron triangle.

The classical way to visualize project constraints is by visualizing a triangle, where cost, time, and scope represent the three sides of the triangle. Any request to replace one of the sides requires at least one other side to be lengthened, or quality will suffer. For example, adding scope requires us to add resources in order to achieve the previous schedule.

While the triangle metaphor is clear, it doesn’t completely ring true.

The visualization of the timebox more intuitively represents the relationship between cost, time and capacity (scope). Further, it allows us to more explicitly demonstrate the impact of scope changes on quality, cost, and time.

To use our timebox visualization, we have to define the units of work that fill up the timebox.

A unit of work

A unit of work represents both the functionality that is delivered and the quality of the functionality. This is the concept that many managers struggle to grasp. People often think of “function” as the deliverable and “quality” as a characterization of the deliverable. This representation can lead to dysfunctional decision making. Any effective approach to managing projects must recognize that quality and functionality both consume capacity.

unit of work

To deliver the functionality that supports any particular requirement, we can think of the unit of work as having two tightly-linked components: implementing the functionality and implementing the functionality with good quality. Poorly written code, for an isolated requirement, can take less time than well written code. The extra time spent doing it right is part of the quality component. Writing tests and documentation (when appropriate) are also part of the quality component.

Investments in quality in the early stages of a project will have a positive impact on the time it takes to deliver future units of work. With an incremental development paradigm, we are assuming that those benefits, when realized, will be implicitly represented by the time estimates for future work. We won’t depend upon those benefits to impact deliverables within the current timebox.

When planning for incremental delivery, each unit should represent something that the customer can use as soon as it is delivered. At a minimum, a work unit would represent all of the functionality to support a single use case. By delivering in use-case-sized units, we enable our users to provide us with feedback about the software.

The largest scope that should be represented in a single unit is a market requirement. We’ve defined our requirements to be both atomic and complete. Therefore, nothing less than or more than a single requirement can be delivered and achieve value. Delivery of a requirement allows our stakeholders to provide us with feedback about the ROI.

How big should a timebox be?

A timebox should be anywhere from two to six weeks, but there are some exceptions. Smaller, more tightly knit teams can operate with shorter timeboxes. Teams with less release-process overhead can operate cost-effectively with smaller timeboxes. There’s a good post and discussion about how long it takes to make timeboxes at The Pragmatic Architect (www.thepragmaticarchitect.com/). Mishkin Berteig also has a good post, with some differing opinions of identifying the pros and cons of short iterations (www.agileadvice.com/archives/2006/01/the_pros_and_co.html).

One very effective approach to minimizing release overhead is to apply continuous integration techniques to the build/test/release cycle for the project. An introduction to continuous integration can be found at Tyner Blain (http://tynerblain.com/blog/2006/05/08/foundation-series-continuous-integration/).

We think a good way to approach it is to start with a four-week cycle and extend or shorten it based on stakeholder preference balanced with the reality of our development environment. For larger teams, we usually end up with a four-week cycle. The length of the cycle can be changed as we get feedback on our process efficiency.

Filling a timebox

We can fill up a timebox with the work-units representing several requirements. Ideally, they are the highest priority requirements. Different requirements will take different amounts of time to implement. The timebox below shows the “original” schedule.

original schedule

We see that every work unit has both functionality and quality components. We don’t want to intentionally plan to deliver functionality without quality. Also note that some units are larger than others. This represents requirements with varying implementation estimates.

Interdependence between tasks is where the project manager helps the product manager select requirements to include in a particular timebox. We treat interdependence (such as user-access-controls being dependent on an authentication system like LDAP) as a constraint, and do not explicitly represent them within the timebox. There are obvious benefits to using timeboxes in order to orchestrate incremental development. Where the timebox really shines is when the requirements change during the course of a project.

Dealing with new requirements

When we receive new requirements, they are represented as changes—adding, removing, or modifying existing requirements. When the changes have no impact on the implementation estimate (or on other requirements) we don’t have to make any changes to the schedule. When requirements are removed, we have an easy problem to solve—which, if any, requirements can be “pulled forward” into the timebox?

When new requirements are added, or changes cause the implementation estimates to grow, we have to adjust our plan/schedule to make room for the new requirements.

There is a two-part article at Tyner Blain about scheduling requirements changes. Check it out to improve your ability to manage those changes while staying sane.

For this article, however, assume that changes are being requested for the next timebox—one that has already been planned, but has not yet begun.

Adapting the plan to these changes requires one of four approaches. We can present these approaches as alternatives during the change-request approval process. Or, when change is inevitable, we can use any of these four approaches to make it happen.

  • Sacrifice quality to increase functionality
  • Increase cost to increase functionality
  • Increase time to increase functionality
  • Delay some functionality to deliver other functionality

Sacrifice quality to increase functionality

We can, and too many development teams do, sacrifice quality to deliver extra functionality without impacting costs or delivery dates. While not generally advisable, it would be naïve to pretend that this option doesn’t exist. Only by understanding it can we choose not to use it.

When we choose the sacrifice quality approach, we incur a code-debt. A code-debt is our project taking a loan against our code-base in the short term to resolve otherwise impossible constraints (no extra budget, can’t miss the deadline, can’t delay anything). Poor quality code comes with a long-term cost. It introduces risk into the delivery. This risk manifests as a negative expected value (think of it as the interest on the loan). In layman’s terms, the expected value is a calculation that serves as the best prediction of a future value. In financial gobbledygook, it is the probability-weighted average value of all possible outcomes.

Poorly written code also makes it more expensive to write new code in the future (think of this as the principal on the loan). Until we invest time to fix the quality of the code (refactor, test, etc.), we will continue to incur costs.

The following diagram shows what this would look like. We have “removed” quality from four previously scheduled requirements, in order to add two “new” requirements—also with poor quality.

sacrificing quality

We have sacrificed quality on some requirements (work components) including the new (red) requirements in order to squeeze them into our timebox. This allows us to deliver previously committed functionality with previously established costs and scheduling. It does not allow us to deliver previously committed quality levels. One reason that many managers perceive this as a loophole is that quality levels are often not committed for projects in advance.

Increase cost to increase functionality

Another approach is to increase the capacity of the implementation team to meet increased demands. This can mean extra hours for the current team, re-tasking people from other projects to join the team, or bringing in contractors to temporarily increase capacity.

Brooks’ law (http://en.wikipedia.org/wiki/Brooks’_law) states that adding people to a project that is running late only increases the delays. However, we are looking at the schedule for a timebox that has not yet begun—we are not trying to recover a delayed project. Therefore, Brooks’ law does not apply in this case.

The following diagram shows that by increasing the cost (and shuffling requirements around visually) we can deliver more functionality without sacrificing quality.

increasing cost

We have increased the height of the timebox visually, allowing more room to make space for the new requirements.

There are always inefficiencies when adding capacity. If we add hours to existing workloads, people get burned out. If we add people, there is overhead in helping them get up to speed. The benefit of this approach is that we don’t sacrifice quality or timing to be able to deliver the new requirements. The downside is that we don’t get 100% efficient use of people.

Increase time to increase functionality

When we have the ability to do so, extending a particular release may make sense. We can extend the period of a single timebox; say from four weeks to five weeks, to incorporate additional functionality. The following diagram shows how a time extension creates more capacity for implementing the requirements.

Deadlines are often arbitrary. We should always explore the possibility of delaying the end of the timebox. But don’t extend the timebox more than 50%, or you lose the benefits of having incremental delivery.

“Incremental delivery is a key component of most software projects today—it allows us to deliver the most valuable elements of a system first, which allows our customers to start getting benefit from the system earlier. As additional features are developed, and additional use cases are enabled, they are delivered to the customers, who get incremental value from those features. This can have a significant impact on ROI projections for a project—and can be the difference between getting the deal and losing it.”

Why Incremental Delivery is Good, Tyner Blain

This strategy is most often used when changes to requirements increase the implementation effort, but re-organizing the delivery plan is too complex. This approach also makes a lot of sense when the anticipated value of the requirements in the current timebox is too high to delay.

Delay some functionality to deliver other functionality

Many times, there are political ramifications to delaying the release. Unfortunately, politics trumps process. Budget constraints are more common than they were 10 years ago when the dot-com boom was starting. When faced with no ability to extend the time or increase the cost, we must make a decision. Either sacrifice quality, or delay other functionality. Since we’ve prioritized our requirements based on the value they provide to the business, it is usually easy to determine what to delay.

First, we identify which previously scheduled requirements are lower priority than the new requirements. Then we understand which of those requirements has the lowest cost of delay. After confirming with our stakeholders, we delay those requirements to the next iteration as shown in the following diagram.

delaying requirements

Summary

We’ve never had a project where we didn’t have to address scope creep (and other changes to requirements for an ongoing project). Timeboxing gives us the ability to easily manage those changes. It also presents us with a very clear way to visualize and communicate the alternatives represented in the four methods.

Categories: Requirements
Scott Sehlhorst

Scott Sehlhorst

Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. Scott is a product management and strategy consultant, and a visiting lecturer for DIT's Product Management program. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers. You can reach Scott at scott@tynerblain.com, or join in the conversation on the Tyner Blain blog.

 

Looking for the latest in product and data science? Get our articles, webinars and podcasts.