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:
- working on one project at a time;
- releasing early and often;
- adapting your plans;
- keeping your options open; and
- 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.
WebinarMaximizing Value with Agile Release Planning
CommentaryA Tale of Two Vacations
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.
- 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."
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.
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.
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 releasesScenario 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!
Benefits for Programmers
Frequent releases are good for the organization. What's it worth to developers? Releases are painful, with flag days and repository freezes and rushes to complete, right?
Slow down. Breathe. Frequent releases can actually make your life easier.
By delivering tested, working, valuable software to your stakeholders regularly, you increase trust. Your stakeholders request a feature and soon see results. There's quick feedback between planning a release and getting the software. You will also get feedback from stakeholders more quickly. This allows you to learn and adapt.
There are technical benefits too. One secret of XP is that doing hard things often and in small doses takes away most of the risk and almost all of the pain. If you have the discipline to set up the necessary infrastructure to make a release at any point (with continuous integration and a ten-minute build), doing so takes only slightly more work than checking in your code and running the complete test suite.
Imagine eliminating all of the stress of tracking down changes from a dozen branches and trying to merge multiple new features simultaneously to make a demo for a trade show next week that you just found out about on Thursday morning... because you can make a release at any time. Life is much better this way.
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.
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", http://earlystagevc.typepad.com/earlystagevc/2005/09/writely_is_the_.html.
3"Writely - The Back Story", http://earlystagevc.typepad.com/earlystagevc/2006/03/same_steve_and_j.html.
4"Only in a bubble is Google's web WP an Office-killer", http://www.theregister.co.uk/2006/03/10/google_writely_analysis/.
Customers and Frequent Releases
"Our customers don't want releases that frequently!"
This may be true. Sometimes your customers won't accept releases as frequently as you deliver them. They may have regulatory requirements that necessitate rigorous testing and certification before they can install new versions.
Sometimes, resistance to frequent releases comes from the hidden costs of upgrading. Perhaps upgrades require a difficult, costly installation process. Perhaps your organization has a history of requiring a series of hotfixes before a new release is stable.
Whatever the reason, the key to making frequent releases is to decrease the real or perceived costs of upgrading. Add an upgrade feature that notifies users of new versions and installs them automatically. Provide well-tested upgrade utilities that automatically convert user data.
Hosted applications, such as web applications, provide the ultimate in release flexibility. These allow you to release at any time, possibly without users even noticing. Some XP teams with hosted software and a mature set of existing features actually release every day.
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).
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.
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.
- No Bugs
"Done Done" and Release Planning
"Done done" applies to release planning as well as stories. Just as you shouldn't postpone tasks until the end of an iteration, don't postpone stories until the end of a release.
Every feature should be "done done" before you start on the next feature. This means you need to schedule stories for reports, administration interfaces, security, performance, scalability, UI polish, and installers as appropriate. In particular, schedule bug-fix stories right away unless you've decided that they're not worth fixing in this release.
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.
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:
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 in Action
A few years ago, my wife and I took a two-month trip to Europe. It was easily the biggest, most complicated trip we've taken. We knew we couldn't plan it all in advance, so we used an adaptive approach.
We started with our vision for the trip. No, we didn't write a vision statement (she won't let me be that geeky) but we did agree that our goal for the trip was to visit a wide variety of European cities instead of going to one place and staying there. We discussed the countries we wanted to see, but we didn't make any decisions that would commit us to visiting a particular set.
We identified the last responsible moment for various decisions in our trip. Airline tickets generally get more expensive over time, so we booked our flight to London months in advance and made plans to stay with relatives there at the beginning and end of our trip. Hotels, however, only need a few days of advance notice. (In fact, too much advance notice means that they might lose your reservation.)
We also took steps that would give us more options. We found a good guidebook that covered all of Europe. We purchased a EuroRail pass, which allowed us to use Europe's excellent rail system to travel through the continent. Although we thought we knew which countries we intended to visit, we spent extra money for a pass that would allow us to visit any European country.
With these general decisions made, we left the details for the last responsible moment. While on the trip, a few days before leaving for our next destination, we decided which country and city to visit next. We stopped by the train station, looked up departure times, and made reservations when necessary. We looked up candidate hotels in our guidebook and emailed the three most promising, then went back to enjoying the current city. The next day, we confirmed one of the hotel reservations. On the last day, we lazed about, picked a time to leave from list of train departure times, then boarded the train. We would arrive in the new city four or five hours later, drop off our belongings at the hotel, and go explore... then start the process over by thinking about the next city and country.
This approach not only gave us flexibility, it was easy and relaxing. Because we only made our reservations a day or two in advance, no hotel ever lost or confused our reservations. If we found that we particularly enjoyed a city, we stayed longer. If we didn't like it, we left early. On previous vacations, we had been slaves to a pre-planned itinerary, fretting over details for the entire trip. On this much longer and more complicated trip, we only had to worry about the details for our next few days.
The flexibility also allowed us to experience things that we never would have otherwise. In Italy, we discovered that our intention to go to Turkey would eat up a huge amount of time in travel. We exploited our EuroRail passes and went to northern Europe instead and ended up having some of our most memorable experiences in cities we had never expected to visit.
By creating a rough plan in advance, keeping our options open, and making detailed decisions at the last responsible moment, we had a much better vacation than we would have had otherwise. Similarly, when you use adaptive planning in software development, unpredictable opportunities arise and allow you to increase the value of your software.
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.
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.
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.
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.