The Art of Agile Development: Release Planning

The second edition is now available! The Art of Agile Development has been completely revised and updated with all new material. Visit the Second Edition page for more information, or buy it on Amazon.

in 99 words

Maximize your return on investment by:

  1. working on one project at a time;
  2. releasing early and often;
  3. adapting your plans;
  4. keeping your options open; and
  5. planning at the last responsible moment.

Use timeboxing to control your schedule. Set the release date, then manage scope to meet that date. This forces important prioritization decisions and makes the endpoint clear.

Prioritized Minimum Marketable Features (MMFs) and stories form the body of your plan. Demonstrate your progress as you develop and use that feedback to revise your plan.

To minimize rework, develop the details of your requirements at the last responsible moment.


Maximizing Value with Agile Release Planning


A Tale of Two Vacations

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

Release Planning

Product Manager

We plan for success.

Imagine you've been freed from the shackles of deadlines. "Maximize our return on investment," your boss says. "We've already talked about the vision for this project. I'm counting on you to work out the details. Create your own plans and set your own release dates—just make sure we get a good return on our investment."

Now what?

One Project at a Time

First, work on only one project at a time. Many teams work on several projects simultaneously, which is a mistake. Task switching has a substantial cost: "[T]he minimum penalty is 15 percent... Fragmented knowledge workers may look busy, but a lot of their busyness is just thrashing." [DeMarco 2002]. Working on one project at a time allows you to release each project as you complete it, increasing the total value of your work.

Consider a team that has two projects. In this simplified example, each project has equal value: when complete, each project will yield $ in value every month. Each project takes three months to complete.

Although I'm describing value in dollar signs, money isn't the only source of value. Value can be intangible as well.

In Scenario A (see Figure), the team works on both projects simultaneously. To avoid task-switching penalties, they switch between projects every month. They finish Project 1 after five months and Project 2 after six. At the end of the seventh month, the team has earned $$.

In Scenario B, the team works on just one project at a time. They release Project 1 at the end of the third month. It starts making money while they work on Project 2, which they complete after the sixth month, as before. Although the team's productivity didn't change—the projects still took six months—they earned more money from Project 1. By the end of the seventh month, they earned $$$. That's nearly twice as much value with no additional effort.

Something this easy ought to be criminal. What's really astounding is the number of teams that work on simultaneous projects anyway.

figure (release_planning__multitasking.gif)

Figure. Effects of multitasking on value

Release Early, Release Often

Releasing early is an even better idea when you're working on a single project. If you group your most valuable features together and release them first, you can achieve startling improvements in value.

Consider another example team. This team has just one project. In Scenario A (see Figure), they build and release it after six months. The project is worth $$ per month, so at the end of the seventh month, they've earned $$.

In Scenario B, the team groups the most valuable features together, works on them first, and releases them after three months. The first release starts making $ per month. They then work on the remaining features and release them at the end of the sixth month. As before, their productivity hasn't changed. All that's changed is their release plan. Yet due to the income from the first release, the team has made $$$$ by the end of the end of the seventh month—nearly triple that of Scenario A with its single release.

figure (release_planning__multiple_releases.gif)

Figure. Effect of Frequent Releases on Value

These scenarios are necessarily simplified. Software by Numbers [Denne & Cleland-Huang] has a more sophisticated example that uses real numbers and calculates value over the entire life of the product (see Table). In their example, the authors convert a five-year project with two end-of-project releases (Scenario A) into five yearly releases ordered by value (Scenario B). As before, the team's productivity remains the same.

Example. Realistic example of frequent releases

                            Scenario A       Scenario B
  Total Cost              | $4.3 million   | $4.712 million
  Revenue                 | $5.6 million   | $7.8 million
  Investment              | $2.76 million  | $1.64 million
  Payback                 | $1.288 million | $3.088 million
  Net Present Value @ 10% | $194,000       | $1.594 million
  Internal Rate of Return | 12.8%          | 36.3%

Scenario A is a marginal investment somewhat equivalent to obtaining a 12.8% interest rate. It requires an investment of $2.76 million and yields profits of $1.288 million. Considering the risk of software development, the investors can put that money to better use elsewhere. The project should not be funded.

Scenario B—the same project released more often—is an excellent investment somewhat equivalent to obtaining a 36.3% interest rate. Although Scenario B costs more because it conducts more releases, those releases allow the project to be self-funding. As a result, it requires a smaller investment of $1.64 million and yields profits of $3.088 million. This project is well worth funding.

Look at these results again. Each of these examples shows dramatic increases in value. Yet nothing changed except the order in which the teams released their features!

How to Release Frequently

Releasing frequently doesn't mean setting aggressive deadlines. In fact, aggressive deadlines extend schedules rather than reducing them [McConnell 1996] (p.220). Instead, release more often by including less in each release. Minimum marketable features [Denne & Cleland-Huang 2004] are an excellent tool for doing so.

A minimum marketable feature, or MMF, is the smallest set of functionality that provides value to your market, whether that market is internal users (as with custom software) or external customers (as with commercial software). MMFs may provide value in many ways, such as competitive differentiation, revenue generation, and cost savings.

As you create your release plan, think in terms of stakeholder value. Sometimes it's helpful to think of stories and how they make up a single MMF. Other times, you may think of MMFs that you can later decompose into specific stories. As you brainstorm, don't forget the minimum part of minimum marketable feature—try to make each feature as small as possible.

Once you have minimal features, group them into possible releases. This is a brainstorming exercise, not your final plan, so try a variety of groupings. Think of ways to minimize the number of features needed in each release.

The most difficult part of this exercise is figuring out how to make small releases. It's one thing for a feature to be marketable, and another for a whole release to be marketable. This is particularly difficult when you're launching a new product. To succeed, focus on what sets your product apart, not the features it needs to match the competition.

An Example

Imagine you're the product manager for a team that's creating a new word processor. The market for word processors is quite mature, so it might seem impossible to create a small first release. There's so much to do just to match the competition, let alone to provide something new and compelling. You need basic formatting, spellchecking, grammar checking, tables, images, printing... the list goes on forever.

Approaching a word processor in this way is daunting to the point where it may seem like a worthless effort. Rather than trying to match the competition, focus on the features that make your word processor unique. Release those features first—they are probably the features that have the most value.

Suppose that the competitive differentiation for your word processor is its powerful collaboration capabilities and web-based hosting. The first release might have four features: basic formatting, printing, web-based hosting, and collaboration. You could post this first release as a technical preview to start generating buzz. Later releases could improve on the base features and justify charging a fee: tables, images, and lists in one release, spellchecking and grammar checking in another, and so on.

Lest this seem foolish, consider Writely, the online word processing application. It doesn't have the breadth of features that Microsoft Word does, and it probably won't for many years. Instead, it focuses on what sets it apart: collaboration, remote document editing, secure online storage, and ease of use.1


According to venture capitalist Peter Rip, the developers released the first alpha of Writely two weeks after they decided to create it.2 How much is releasing early worth? Ask Google. Ten months later, they bought Writely,3 even though Writely still didn't come close to Microsoft Word's feature set.4 Writely is now known as Google Docs.

2"Writely is the seed of a Big idea",

3"Writely - The Back Story",

4"Only in a bubble is Google's web WP an Office-killer",

Adapt Your Plans

If such significant results are possible from frequent releases, imagine what you could accomplish if you could also increase the value of each release. This is actually pretty easy: after each release, collect stakeholder feedback, cancel work on features that turned out to be unimportant, and put more effort into those features that stakeholders find most valuable.

With XP, you can change your plans more often than once per release. XP allows you to adjust your plan every iteration. Why? To react to unexpected challenges quickly. More importantly, it allows you to take advantage of opportunities. Where do these opportunities come from? You create them.

The beginning of every software project is when you know the least about what will make the software valuable. You might know a lot about its value, but you will always know more after you talk with stakeholders, show them demos, and conduct actual releases.

As you continue, you will discover that some of your initial opinions about value were incorrect. No plan is perfect, but if you change your plan to reflect what you've learned—if you adapt—you create more value.

To increase the value of your software, create opportunities to learn. Think of your plan as a plan for learning as much as it is a plan for implementation. Focus on what you don't know. What are you uncertain about? What might be a good idea? Which good ideas can you prove in practice? Don't just speculate—create experiments. Include a way of testing each uncertainty.

For example, if you were creating a collaborative online word processor, you might not be sure how extensive your support for importing Microsoft Word documents should be. Some sort of support is necessary, but how much? Supporting all possible Word documents would take a long time to implement and prevent you from adding other, possibly more valuable features. Too little support could damage your credibility and cause you to lose customers.

To test this uncertainty, you could add a rudimentary import feature to your software (clearly marked "experimental"), release it, and have it create a report on the capabilities needed to support the types of documents that real users try to import. The information you gather will help you adapt your plan and increase your product's value.

Web users are used to "beta" web applications, so releasing an experimental feature is possible in that context. A project with less forgiving users may require the use of a pre-release program, focus groups, or some other feedback mechanism.

Keep Your Options Open

To take the most advantage of the opportunities you create, build a plan that allows you to release at any time. Don't get me wrong—the point is not to actually release all the time, but to enable you to release at any time.

At any time, you should be able to release a product that has value proportional to the investment you've made.

Why do this? It allows you to keep your options open. If an important but completely new opportunity comes along, you can release what you have and immediately change directions to take advantage of the opportunity. Similarly, if there's some sort of disaster, such as the project's surprise cancellation, you can release what you have anyway. At any time, you should be able to release a product that has value proportional to the investment you've made.

To release at any time, build your plan so that each story stands alone. Subsequent stories can build on previous stories, but each one should be releasable on its own. For example, one item in your plan might be "Provide login screen," and the next might be "Allow login screen to have client-specific branding." The second item enhances the first, but the first is releasable on its own.

Suppose you're creating a system that gets data from a user, validates the data, and writes it to a database. You might initially create a story for each step: "Get data," "Validate data," and "Write data to database." These are sometimes called horizontal stripes. This is an easy way to create stories, but it prevents you from releasing, or even effectively reviewing, the software until you finish all three stories. It gives you less flexibility in planning, too, because the three stories form an all-or-nothing clump in your schedule.

A better approach is to create stories that do all three tasks, but provide narrower individual utility. For example, you might create the stories "Process customer data," "Process shipping address," and "Process billing information." These are vertical stripes (see Figure).

figure (release_planning__horizontal_and_vertical_stripes.gif)

Figure. Horizontal and vertical stripes

Don't worry too much if you have trouble making your stories perfectly releasable. It takes practice. Releasable stories give you more flexibility in planning, but a few story clumps in your plan won't hurt much. With experience, you'll learn to make your plans less lumpy.

How to Create a Release Plan

There are two basic types of plans: scopeboxed plans and timeboxed plans. A scopeboxed plan defines the features the team will build in advance, but the release date is uncertain. A timeboxed plan defines the release date in advance, but the specific features that release will include are uncertain.

Some people try to fix the release date and features. This can only end in tears; given the uncertainty and risk of software development, making this work requires adding a huge amount of padding to your schedule, sacrificing quality, working disasterous amounts of overtime, or all of the above.

Timeboxed plans are almost always better. They constrain the amount of work you can do and force people to make difficult but important prioritization decisions. This requires the team to identify cheaper, more valuable alternatives to some requests. Without a timebox, your plan will include more low-value features.

To create your plan, first choose your release dates. I like to schedule releases at regular intervals, such as once per month and no more than three months apart.

Does it seem odd to set the release date before deciding on features or estimates? Don't worry—you'll constrain your plan to fit into the time available.


Now flesh out your plan by using your project vision to guide you in brainstorming minimum marketable features. Decompose these into specific stories and work with the programmers to get estimates. Using the estimates as a guide, prioritize the stories so that the highest-value, lowest-cost stories are done first. (For more details, see The Planning Game later in this chapter).

To brainstorm features and stories, use the vision to guide you, turn to interaction designers for ideas, and involve stakeholders as appropriate. Classic requirements gathering techniques may also help; see "Further Reading" at the end of this section for suggestions.

The end result will be a single list of prioritized stories. Using your velocity, risk factors, and story estimates, you can predict how many stories each release will include (see Risk Management later in this chapter). With that information as a guide, discuss options for reducing costs and splitting stories so that each release provides a lot of value.

Iteration Planning

This final list of stories is your release plan. Post it prominently (I use a magnetic whiteboard—see Figure) and refer to it during iteration planning. Every week, consider what you've learned from stakeholders and discuss how you can use that information to improve your plan.

figure (release_planning__release_planning_board.gif)

Figure. A release planning board

No Bugs

Planning at the Last Responsible Moment

It takes a lot of time and effort to brainstorm stories, estimate them, and prioritize them. If you're adapting your plan as you go, some of that effort will be wasted. To reduce waste, plan at the latest responsible moment. The latest responsible moment is the last moment at which you can responsibly make a decision (see XP Concepts in Chapter 3). In practice, this means that the further away a particular event is, the less detail your release plan needs to contain.

Another way to look at this is to think in terms of planning horizons. Your planning horizon determines how far you look into the future. Many projects try to determine every requirement for the project up front, thus using a planning horizon that extends to the end of the project.

To plan at the latest responsible moment, use a tiered set of planning horizons instead. Use long planning horizons for general plans and short planning horizons for specific, detailed plans, as shown in Figure.

figure (release_planning__planning_horizons.gif)

Figure. Planning horizons

Your planning horizons depend on your situation and comfort level. The more commitments you need to make to stakeholders, the longer your detailed planning horizons should be. The more uncertain your situation is, or the more likely you are to learn new things that will change your plan, the shorter your planning horizons should be. If you aren't sure which planning horizons to use, ask your mentor for guidance. Here are some good starting points:

Customer Tests
  • Define vision for the entire project.

  • Define the release date for the next two releases.

  • Define the minimum marketable features for the current release and start to place features that won't fit in this release into the next release.

  • Define all of the stories for the current feature and most of the current release. Place stories that don't fit into the next release.

  • Estimate and prioritize stories for the current iteration and the following three iterations.

  • Determine detailed requirements and customer tests for the stories in the current iteration.

Adaptive Planning and Organizational Culture

Does the idea of spending two months travelling in a foreign country without advance hotel reservations seem scary? In practice, it was easy and relaxing, but when I tell the story of our adaptively-planned trip to Europe (see the "Adaptive Planning in Action" sidebar), audiences get nervous.


Organizations often have a similar reaction to adaptive planning. An adaptive plan works to achieve a vision. However, just as my wife and I achieved our vision—"have fun visiting a lot of European cities"—but didn't know exactly which cities we would visit, an adaptive team will achieve its vision even though it cannot say exactly what it will deliver.

No aspect of agile development challenges organizational culture more than the transition to adaptive planning. It requires changes not only to the development team, but to reporting, evaluation, and executive oversight as well. The choice of adaptive planning extends to surprisingly diverse parts of the project community, and people often have a shocked or emotional reaction to the idea.

As a result, you may not be able to influence a change to adaptive planning. Unless you have executive support, any change that does occur will probably be slow and gradual. Even with executive support, this change is difficult.

Work within your organization's culture.

You can work within your organization's culture to do adaptive planning under the radar. Use adaptive planning, but set your planning horizons to match the organization's expectations. Generally, estimating and prioritizing stories for the remainder of the current release is enough. This works best if you have small, frequent releases.

As your stakeholders and executives gain trust in your ability to deliver, you may be able to shorten your detailed planning horizons and migrate further towards an adaptive plan.


I thought we were supposed to release every week. Is this different?

You may be confusing iterations with releases. Although the team should release software to internal stakeholders every week as part of the iteration demo, you may not choose to release to end-users or real customers that often.

Weekly releases are a great choice if you have the opportunity. Your ability to do so will depend on your business needs.

If we don't plan the entire project in detail, what should we tell our stakeholders about our plans?

Although you may not plan out all of the details of your project in advance, you should have plenty of detail to share with stakeholders. You should always know the overall vision for the project. Depending on your planning horizons, you will probably have a list of the features for the next release as well as a planned date for that release. You will also have specific, estimated stories for near-term work.

If your stakeholders need more information or predictability, you may need longer planning horizons. In any event, be sure to let stakeholders know that this is your current plan and that it is subject to change if you find better ways of meeting the project vision.

Planning at the last responsible moment means we can't show exactly what we'll deliver. Doesn't that require too much trust from stakeholders?

Any development effort requires that the organization trust that the team will do its job. If stakeholders require a detailed plan in order to trust you, use longer planning horizons that allow you to provide the plan they desire.

If we use short planning horizons, how can we be sure that we'll deliver on the project vision?

If you're not sure you can deliver on the project vision, focus your plan on discovering whether you can. You may need to extend your planning horizons or create a small, limited-availability release to test crucial concepts. The details depend on your situation, so if you're not sure what to do, ask your mentor for guidance.

No matter your decision, clearly convey your concern to stakeholders and let them know how you intend to address the uncertainty.


When you create, maintain, and communicate a good release plan, the team and stakeholders all know where the project is heading. The plan shows how the team will meet the project vision, and team members are confident that the plan is achievable. You complete features and release high-quality software regularly and consistently.

If you are adapting your plan well, you consistently seek out opportunities to learn new things about your plan, your product, and your stakeholders. As you learn, you modify your plan to take advantage of new insights. Stakeholders and the team agree that each release is better than originally planned.


Not all of these ideas are appropriate for everyone. I've put the easiest ones first, but even the easy ones have limitations.

Working on one project at a time is an easy, smart way to increase your return on investment. Despite its usefulness, working on one project at a time is anathema to some organizations. Proceed with caution.

Releasing frequently requires that your customers and users be able to accept more frequent releases. This is a no-brainer for most web-based software because users don't have to do anything to get updates. Other software might require painful software rollouts, and some even require substantial testing and certification. That makes frequent releases more difficult.

Adaptive planning requires that your organization define project success in terms of value rather than "delivered on time, on budget, and as specified." This can be a tough idea for some organizations to swallow. You may be able to assuage fears about adaptive plans by committing to a specific release date but leaving the details of the release unspecified.

Test-Driven Development
Continuous Integration
Incremental Design And Architecture

Keeping your options open—that is, being ready to release, and thus change directions, at any time—requires a sophisticated development approach. Practices such as test-driven development, continuous integration, and incremental design and architecture help.

Tiered planning horizons require a cohesive vision and regular updates to the plan. Use them when you can reliably revisit the plan at least once per iteration. Be sure your team includes a product manager and on-site customers who are responsible for maintaining the plan.

Finally, be cautious of plans without a predefined release date or a release date more than three months in the future. Without the checkpoint and urgency of a near-term release, these plans risk wandering off course.


The classic alternative to adaptive release planning is predictive release planning, in which the entire plan is created in advance. This can work in stable environments, but tends to have trouble reacting to changes.

Incremental Design And Architecture

If you don't use incremental design and architecture, [Denne & Cleland-Huang] provide a sophisticated Incremental Funding Methodology that shows how to prioritize technical infrastructure alongside features. However, XP's use of incremental design neatly sidesteps this need.

Finally, teams with an established product and a relatively small need for changes and enhancements don't always need a release plan. Rather than thinking in terms of features or releases, these teams work from a small story backlog and release small enhancements every iterations. In some cases, they conduct daily deployment. You could think of this as an adaptive plan with a very short planning horizon.

Further Reading

Software by Numbers [Denne & Cleland-Huang] provides a compelling and detailed case for conducting frequent releases.

Agile Development Ecosystems [Highsmith] has an excellent discussion of adaptive planning in chapter 15.

Lean Software Development [Poppendieck & Poppendieck] discusses postponing decisions and keeping your options open in chapter 3.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.