Chapter 13. Release Planning Essentials

“You improvise. You adapt. You overcome.”

—Clint Eastwood in Heartbreak Ridge

Release planning is the process of creating a very high-level plan that covers a period longer than an iteration. A typical release will cover perhaps three to six months and maybe three to twelve or more iterations, depending on how long the iterations are. A release plan is important for a number of reasons.

First, it helps the product owner and the whole team decide how much must be developed and how long that will take before they have a releasable product. The sooner the product can be released (and the better it is when it’s released), the sooner the organization will begin earning a return on its investment in the project.

Second, a release plan conveys expectations about what is likely to be developed and in what timeframe. Many organizations need this information because it feeds into other strategic planning activities.

Third, a release plan serves as a guidepost toward which the project team can progress. Without the concept of a release, teams move endlessly from one iteration to the next. A release plan provides context that allows iterations to combine into a satisfying whole. This is a fundamental concern with any iterative process, not just agile ones. A hiker who wishes to reach the summit of a mountain may head for the highest peak he sees. However, once he reaches that summit he learns that it was a false peak. A higher summit had been obscured by the one he has reached. The hiker sets off toward the higher summit, only to find that it, too, is a false peak, and an even higher summit is now visible. This rather circuitous way of hiking up a mountain can apply equally to iterative projects. Fortunately, the problems it creates are eliminated by having a release plan that shows a team’s current expectation of where they ultimately wish to arrive.

The Release Plan

Part of planning a release is determining how much can be accomplished by what date. In some cases, we start with a date and see how much can be finished by then. In other cases, we start with a set of user stories and see how long it will take to develop them. In both cases, once a team has an initial answer, it is assessed against the organization’s goals for the project: Will the product developed make the desired amount of money? Will it save enough money? Will the product capture the target market share? If not, perhaps a longer or shorter project may achieve an acceptable set of goals.

At a cursory level, determining how much work will fit into a release and what user stories that will be is a very straightforward process. Multiplying the planned number of iterations by either the expected or known velocity of the team gives us the total amount of work that can be performed. We then select the number of user stories that will fit and are done. Suppose that we wish to ship a new product in six months. We plan to work in two-week iterations, so there will be thirteen iterations during the project. We expect the team’s velocity to be twenty story points or ideal days per iterations. The size of the total project is then 13 × 20 = 260 story points or ideal days. The product owner and team could then discuss all of the stories and prioritize them to deliver the most value possible while paying attention to not going above 260. The release plan itself is usually documented as simply a list of the user stories that will be developed during the project.

During release planning, we do not want to create a plan that indicates which developers will work on which user stories or tasks, or the sequence in which work will be performed within an iteration. Creating a plan with that level of detail during release planning is dangerous and misleading. Decisions about who works on what and the sequence of activities are best left to the individuals working on those tasks and are best deferred as long as possible. Additionally, remember that items in a release plan are user stories, which are descriptions of the functionality to be delivered, not individual engineering tasks to be performed. During release planning, it is too early, and some user stories may be insufficiently understood to be disaggregated into engineering tasks. As you’ll see in Chapter 14, “Iteration Planning,” the team will eventually disaggregate the user stories of the release plan into their constituent tasks. But they won’t do this until the beginning of the iteration containing those stories.

Naturally, should your project, organization, and work environment warrant it, you can include additional information in a release plan. For example, you may wish to communicate some key assumptions underlying the plan. Most notably, you may want to state assumptions about who is on the team, how long the iterations will be, the date the first iteration will start, and the date the last iteration will finish. Chapter 21, “Communicating about Plans,” will describe some additional useful information you may want to include when communicating about a release plan.

The general steps in planning a release are shown in Figure 13.1. Each of these steps will be described in the sections that follow.

Figure 13.1. The steps in planning a release.

Determine the Conditions of Satisfaction

Before starting to plan a release, it is important to know the criteria by which the project will be evaluated as a success or a failure. For most projects, the ultimate scorecard is the amount of money saved or generated. As leading indicators of whether a project is likely to achieve these financial goals, most projects use the triumvirate of schedule, scope, and resources. For most projects, this means that the product owner’s conditions of satisfaction are defined by a combination of schedule, scope, and resource goals.

The product owner will bring desired targets for each of these factors into almost every release planning meeting. A product owner may want four themes (worth 200 story points) developed in three months without adding personnel, for example. Although a target for each factor is often identified, one factor is usually preeminent. Projects are typically either date-driven or feature-driven. A date-driven project is one that must be released by a certain date but for which the feature set is negotiable. A feature-driven project is one that we would probably like to release as soon as possible but for which we consider the completion of a set of features to be more important.

Estimate the User Stories

Because an estimate represents the cost of developing a user story, it is important that each has been estimated. Imagine that you’ve decided to replace every item of clothing in your closet. You arrive at the mall and start shopping. However, you notice that all the price tags have been removed and that you have no way of knowing the cost of anything. This is what it feels like to be a product owner who is not provided any estimates.

It is not necessary to estimate everything that a product owner may ever want. It is necessary only to have an estimate for each new feature that has some reasonable possibility of being selected for inclusion in the upcoming release. Often, a product owner will have a wish list that extends two, three, or more releases into the future. It is not necessary to have estimates on the more distant work.

Select an Iteration Length

Most agile teams work in iterations of two to four weeks. It’s possible to go slightly longer, and some teams have experimented with even shorter iterations. When planning a release, an appropriate iteration length will need to be chosen. Guidance on doing this is provided in Chapter 15, “Selecting an Iteration Length.”

Estimate Velocity

If the team has experience working together, your best bet is often to use the velocity the team exhibited most recently. Naturally, if the technology or business domain has changed dramatically, it may not be appropriate to use a team’s past velocity. Still, there are techniques you can apply that enable you to make an informed estimate of velocity based on past results. In Chapter 16, “Estimating Velocity,” we will look at such techniques and will also explore options for estimating velocity.

Prioritize User Stories

Most projects have either too little time or too many features. It is often impossible to do everything that everyone wants in the time allowed. Because of this, the product owner must prioritize the features she wants developed. A good product owner will accept ultimate responsibility for prioritizing but will listen to advice from the development team, especially about sequencing. User stories are prioritized based on the guidelines given in the previous part of this book.

Select Stories and a Release Date

At this point, you have an estimate of the team’s velocity per iteration and have an assumption about how many iterations there will be. It’s time to see whether a release can be planned that meets the conditions of satisfaction for the project.

If the project is feature-driven, we can sum the estimates of all needed features and divide by the expected velocity. This will give us the number of iterations necessary to complete the desired functionality.

If the project is date-driven, we can determine the number of iterations by looking at a calendar. Multiplying the number of iterations by the expected velocity will tell us how many story points or ideal days will fit in the release. We can count off that many points or ideal days into the prioritized list of user stories and see how much functionality can be delivered in the desired time.

The next question to be addressed regards how detailed the release plan will be. Some teams in some environments prefer to create a release plan that shows what they expect to develop during each iteration. Other teams prefer simply to determine what they think will be developed during the overall release, leaving the specifics of each iteration for later. This is something for the team to discuss and decide during release planning.

There are advantages and disadvantages to each approach. Obviously, assigning specific features to specific iterations takes more time. However, the additional detail this provides can be useful when coordinating work among multiple teams. On the other hand, not allocating work to specific iterations provides less detail, but it takes much less time. Further, even if we do preliminarily assign work to specific iterations, we do so with less knowledge than we’ll have at the start of each iteration. Undoubtedly, the plan will change as we learn more throughout the project. So the investment of time and effort to assign work to specific iterations should be weighed against this. Still, on some projects it may be worth doing. What I find to be a good compromise is to place specific work into the first one to three iterations, treating the rest of the release plan as one large bucket. It’s almost always worth allocating specific work to the first iteration, especially if it is starting immediately.

Because there are a lot of give-and-take and what-if questions during a typical release planning session, we want an easy way to manipulate what’s in and out of the release and its iterations. The best way of achieving this, assuming everyone is collocated, is to work with 3″ × 5″ note cards or sticky pads with user stories or features written on them. Unlike software, cards are tangible and easily shared.

To plan a release, the product owner selects her top priority items that will fit in the first iteration. Cards are stacked or arranged to indicate which stories comprise each iteration. Figure 13.2 shows one way of doing this. Cards can be arranged like this on a table or a wall. If you’re using a wall, a corkboard is very effective, because cards can be pinned to the board rather than taped to the wall. Because each story card is annotated with an estimate, it is possible to look down each column of an arrangement like Figure 13.2 and verify that each iteration holds the right amount of work.

Figure 13.2. Arranging iterations in columns.

Updating the Release Plan

At this point, the release plan is done. However, it’s important that the release plan isn’t filed away somewhere or put up on a shelf, never to be touched again. The release plan should be revisited and updated with some regular frequency. If the development team’s velocity has remained fairly constant, and iteration planning hasn’t introduced any big surprises, you may want to go as long as four to six weeks without formally updating the release plan. On the other hand, many projects benefit from establishing a rule that the release plan will be revisited after each iteration.

An Example

To tie all of the preceding together, let’s consider a very brief example. We will again use the SwimStats website. Through market research we’ve discovered that coaches and swimmers in our target audience want the features described by the following user stories:

• As a coach, I can define practice sessions.

• As a coach, I can define custom fields I want to track for each swimmer.

• As a swimmer, I can run a report that shows my improvement in all events since a date in the past.

• As a swimmer, I can update my demographic information.

• As a coach, I can send an email to all swimmers on the team.

• As a system administrator, I can configure permissions and user groups.

• As a coach, I can purchase SwimStats and use it for my team.

• As a swimmer, I can compare my times with national records.

• As a coach, I can enter enter the names and demographic information of all swimmers on my team.

• As a swimmer, I can see my best times in each event.

• As a user, I am required to log in and can see only data for which I have permission.

• As a swimmer, I can see all of my times for a specific event.

Determining the Conditions of Satisfaction

The spring swim season starts in four months. The first release of the SwimStats website needs to be available a month before that. The product owner would like as many features as possible, but this is a date-driven project. Something must be releasable in three months, even if it is only the basics for small swim teams. As a start-up, budget is also fixed. The project needs to be done with the one programmer, one database administrator, and one tester who are already on staff.

Estimating

The three developers who will work on the project meet with the product owner. They ask questions about the user stories, and the product owner clarifies the intent of each. The team elects to estimate in story points and assigns the estimates shown in Table 13.1.

Table 13.1. The Prioritized List of Stories

Selecting the Iteration Length

Because the entire project will only be three months, the developers and the product owner agree that four-week iterations are too long. Running four-week iterations just won’t give them enough checkpoints on the team’s progress or enough opportunities for the product owner to steer the project by adjusting priorities. Based on points that will be presented in Chapter 15, “Selecting an Iteration Length,” everyone agrees to run two-week iterations.

Estimating Velocity

This project will be worked on by two programmers and a tester. Using the techniques you’ll learn in Chapter 16, “Estimating Velocity,” they forecast a velocity of eight story points per iteration.

Prioritizing the User Stories

The product owner, based on market research that has been done, prioritizes the stories. The prioritized story list, along with the estimate for each story is shown in Table 13.1.

Selecting the User Stories

Because this is a date-driven project, we know how many iterations there can be. The product owner wants a release out in three months so there is time for six two-week iterations followed by an extra week in case it’s needed. With an estimated velocity of eight points per iteration, this means the release will be planned to include 6 × 8 = 48 story points. The product owner will be able to select up to forty-eight points from Table 13.1 to include in the release.

The user stories in Table 13.1 have been sorted by the product owner in descending order of how valuable she thinks each will be to the initial release of SwimStats. The product owner is allowed to select up to forty-eight points. She initially indicates that she’d like to select the first eight stories, through “As a swimmer, I can compare my times with national records.” This is a total of forty-six points, which is close enough to forty-eight that the product owner agrees to stop there.

However, the developers point out that the story prioritized as the lowest by the product owner is necessary: “As a system administrator, I can configure permissions and user groups.” This story is estimated at three points, which would put the release at forty-nine and over the planned forty-eight. The forty-eight points is a fairly rough guess, and an extra week is planned after the sixth iteration. Some teams may allow for forty-nine points under these circumstances.

The SwimStats team, however, decides not to allow forty-nine points. If a three-point story is being added, at least one point needs to be dropped from the release. The product owner decides to drop the eight-point “As a swimmer, I can compare my times with national records.” This brings the release down to forty-one points. The product owner could add the three-point story, “As a coach, I can send an email to all swimmers on the team” to the release, but she decides to hold off on doing so. If the team gets even one point ahead of schedule, she’d prefer to add back the eight-point story she dropped. This makes the final release plan as shown in Table 13.2.

Table 13.2. The Final Release Plan for SwimStats

Summary

A release plan is a high-level plan that covers a period longer than an iteration. For most teams a release occurs every three to six months, but it is not unusual to have releases more or less frequently, depending on the type of software. At its simplest level, release planning is trivial: Multiply the expected velocity by the number of planned iterations and then select stories whose estimates sum to fill up the release.

A release plan does not have to describe exactly what will be worked on during each iteration. In fact, that level of detail is rarely needed. For most projects it is quite adequate to identify the stories that will be worked on in the first couple of iterations, leaving the remaining stories to be prioritized into specific iterations later.

Release planning is an iterative process that begins by identifying the product owner’s conditions of satisfaction for the project. These usually include goals for the schedule, scope, and resources. If a project cannot be planned that meets the set of initial conditions of satisfaction, the planning process is repeated to see if a lessened set of conditions can be met; perhaps the desired functionality can be delivered a little later or with a larger team.

Once a release plan has been created, it is not left hanging on a wall to rot. It is usually updated at the start of each iteration.

Discussion Questions

1. Is your current project date-driven or feature-driven? What makes it so?

2. In your organization or on your current project, how often should a release plan be updated?