Timing of releases and release planning

Releases themselves should occur at a point in time designated by the product owner when he has evaluated the return on investment and determined that a set of features should be made available to customers or users. The product owner, likely, will have an idea of release timeframes before any work has begun (I needed it yesterday!). There is a frequency at which customers or users would like to see new features, and it is the product owner's responsibility to determine this cadence. For example, in the map application on my new iPhone, I welcome new features and versions anytime they're available! On the other hand, I would not like it if brand new, different iPhones were available with brand new operating systems and user interfaces every month (I think device releases such as these are already a bit too frequent, but the market seems to have proven otherwise, at least for now).

It is necessary that the product owner is able to communicate release plans to other groups within the business; for example, marketing and sales groups in many companies need to communicate about the release ahead of time in order to generate buzz and interest, and it's critical from a business perspective to give those groups a heads-up about what's coming. Most organizations begin selling functionality before it's even finished—signing contracts based upon promises—and as much as I loathe the concept of fixed-scope/fixed-time contracts, there should be at least some indication of when features will land! I'd estimate that release planning happens before the project starts in about 80 percent of cases, and the rest of the time the team either does not do any release planning at all, or release planning occurs after a number of sprints through which the team has discovered its velocity. Regardless of when or how it's created, the product owner and team should revisit the release plan throughout the duration of the project as circumstances will change. It is your responsibility as the ScrumMaster to ensure that this happens.

Don't create the software big dig

You might be familiar with Boston's Central Artery/Tunnel project (aka The Big Dig). The initial project estimate was 2.5 billion dollars with an originally estimated completion year of 1998; estimates increased to 14 billion dollars by 2006, and while considered done by some in 2006, there remains to this day a need to replace 25,000 deteriorating light fixtures, to the tune of an additional 54 million dollars. According to Virginia Greiman of Boston University, "no single catastrophic event or small number of contracts caused costs to escalate. The critical cause was a lack of experience and knowledge about dealing with the complexity and uncertainty" (of giant projects). (http://www.nasa.gov/offices/oce/appel/ask/issues/39/39s_big_dig.html). The people who designed the project were part of a different company than the people who built the structures, and there was not a policy of early and frequent engagement and communication among these thousands of people. The ultimate cost of the Big Dig, sadly, was the loss of life: a woman was crushed in her car and died a few years ago because the glue used to hold the roof in place was insufficient for long-term bonding. There was so much uncertainty and complexity at the beginning of this project that it was foolish for any contractor to bid a defined amount, and foolish for the Massachusetts Turnpike Authority to accept such. However, we live in a world in which low bids and sketchy promises often do win the contract, unfortunately.

There are numerous lessons from Boston's Big Dig that apply to release planning

Integrate early and often to mitigate risks

Encourage team members (and multiple teams if you're on a larger program) to integrate early and often, and to account for these activities in the release plan. Many developers put off merging their work because they don't want to deal with the problems that integration surfaces. As ScrumMaster, you must remind team members that a sprint's features aren't done until one person's code works with everyone else's code and that all test cases pass. It may be difficult for the team to reach this level of done in early sprints for many valid reasons—antiquated build practices, old tools, and so on—but you must help the team develop the ability to ultimately integrate on a continuous basis. Falling short of this will impede the ability of the organization to respond to customers' most pressing needs. You must ensure that your team discuss and address issues such as integration, testing, and a general Definition of Done in release planning initially, and revisit these goals throughout the project. For more ideas, check out Henrik Kniberg's article on version control for Agile teams (http://www.infoq.com/articles/agile-version-control).

Make buffers visible

As ScrumMaster you should encourage your team to communicate realistic estimates and add buffers for when uncertainty is particularly high. This means that the team should pad estimates for the unknown; for example, if your team must leverage a third-party technology in a few sprints from now, the team should buffer those estimates to reflect the unknowns of the integration effort in the release plan. The team could choose to give a low estimate, tell the product owner what he wants to hear, and make him happy in the short term; the trouble is that the team might have to go back to the customer with tail between legs to ask for more money or more time, which I don't advocate as a sustainable practice. Worst case, the team might try to pull off a miracle, resulting in cut corners and quality issues that will only come back to haunt them (or some other poor team) in the future. Teams should pad estimates to compensate for uncertainty and regularly communicate their concerns and fears to the ScrumMaster and product owner. It's always better for the team to have buffered a little too much; in that case, they can just pull another few stories into the release. I'd rather have this situation than my team having to cut stories from a release!

Buffering for uncertainty simply means not planning each sprint to 100 percent maximum capacity. Let's say that our team initially feels that it can accomplish 20 points per sprint, but after a bit more discussion, the team realizes that they should buffer about 25 percent of their capacity for ramp up (they're all new to the project) and maintenance of the existing production version. A 25 percent buffer means that the release commitment would now be 15 points—not 20—per sprint. Makes sense, right? Well, I've met many people who have had extremely negative gut reactions to this concept. I've heard comments such as, "We can't lie to our customer!" or "Management wants to see 100 percent utilization, we can't plan for and only show 75 percent!" Actually, wouldn't teams be lying to the customer if they dismissed the ramp-up time and production support activities that they know they are responsible for and instead stuffed each sprint in release planning to 100 percent? After two or three sprints of working and realizing that they had overcommitted in the first place, they've only managed to delay this inevitable touchy conversation! You see, release planning should be a meaningful discussion between the team and product owner about what's realistic; sometimes this means making some tough decisions and trade-offs. Every product owner I've met says that they'd rather know the concerns and risks as soon as possible so that they have time to make the appropriate decisions. Buffering helps teams create plans that are realistic and sets them up with a better chance of meeting their commitments to the product owner.

Keep in mind that your job as ScrumMaster is to make buffers visible; in fact, since the customer or product owner attends your release planning meeting, he would understand the reasons behind the buffer because he was engaged in an intelligent dialogue about it with the team. Most people recognize buffering as good risk mitigation practice.

If our team finishes the 15 points of work by the first half of the sprint, they should pull the next items from the top of the product backlog to fill up the remainder of the sprint. (They would need to hold a mini-planning session to figure out how much to pull—see Chapter 3, Sprint Planning – Fine-tune the Sprint Commitment.) Let's say they pulled eight additional points of work and were able to complete the eight points in addition to the 15 they originally committed. As a result the team has an observed velocity of 23—a number they can use to re-forecast the release with increased confidence.

The more uncertain the team and product owner are, the more they should buffer. The following screenshot shows an example of buffering for work that is not feature implementation:

Some teams apply a buffer by leaving empty an entire sprint or two at the end, as shown in the following screenshot:

Release planning is like tuning to the standard pitch. Release plans will be off. And maybe off is acceptable to customers, maybe it's not—we'll discover that through playing (sprinting). We want to partner with customers to build the right features to an acceptable level of quality in an acceptable amount of time while making uncertainty and estimated costs visible so that the customer is not surprised. Likewise, we shouldn't expect our customers to know everything about what they want today, because they simply cannot. Remember that a Scrum team should partner with the product owner (from the Agile Manifesto: "customer collaboration over contract negotiation"). In any partner relationship, both parties should operate with full transparency.

Release planning opens up a dialog and an acknowledgement that planning is not a prediction—rather, a forecast—and that some features may need to be traded-off or de-scoped. It can often feel that release planning is not just about a team figuring out what will be in the release but also making tough cuts for features that won't be in the release.

In the following figure, there are three areas: a solutions space (features/user stories/PBIs), timeframes, and business problems that need solutions. The role of the product owner (the guy in the middle there) is to pick the right set of features to solve the current (and projected) business problems within a timely manner (a sprint, a release next year). The difficulty is that the problem and solutions spaces are dynamic. There are always problems to solve—some we know as regularly recurring events (user conference), and yet there are true emergencies from time to time (responding to competitor x, production issue, and so on). The good news is that the product backlog is stocked with many ideas from which the product owner may choose in order to formulate the best possible response. The goal of this game is to line up items in the backlog to the right timeframe in order to satisfy the business need, sort of like when you play a slot machine: if three cherries line up in the middle, you've won. The difference in the technology slot machine is that things just don't ever quite line up perfectly, no matter how hard you try, because of all the interdependencies: a change in one necessitates a change in another. Since the problem and solutions spaces change all the time (and timeframes/deadlines can too, for that matter), planning should be viewed as an ongoing dialog between team and product owner that takes into account the latest changes in these spaces in order to formulate a new best response each time, lining up the cherries as closely as possible.

How to conduct a release planning event?

So your product owner and team have brainstormed a product backlog with features, and everyone is ready to get started. The product owner is ready to pull the lever on the technology slot machine. How do you engage everyone in an effective release planning conversation?

Facilitating the release planning meeting

Your role as ScrumMaster in the release planning meeting is to serve as guide, time-keeper, organizer, and facilitator. Unlike a project manager, you do not make the decisions about scope, time, and cost; in Scrum, that responsibility belongs to the product owner. The release planning meeting is the time for the product owner to present the problems that he is trying to solve and the timeframes that would be most beneficial, and work with the team to figure out the best response.

Participants

The primary participants in release planning are the ScrumMaster, the product owner, and the delivery team members. Other stakeholders may wish to attend. For example, the support representative who had requested some fixes to customer issues wants to attend release planning so that he/she can provide the team with additional context about those issues.

Since he/she is the first line of communication to the customer, he/she is a vested stakeholder and needs to be present. It is important to remember, however, that even though other stakeholders might attend, the product owner still owns the order and depth to which product backlog items are implemented. The ScrumMaster and product owner should work together to identify and invite any appropriate stakeholders ahead of time.

Agenda

The release planning conversation should be just that—a conversation. It should not be a presentation of a plan from product owner to team; rather, the spirit of the meeting is that team members and the product owner share a vision and together create a plan. In order to get the best, most focused discussions, and ensure that you have the results you need, you'll need a well-crafted agenda.

A sample release planning agenda is as follows; please tailor it to meet your needs and remember to keep it as light as possible:

It is imperative that the product owner attends and participates (that is, not on a 'crackberry') during the release planning discussion. In this day and age, there's simply no excuse. If you can't get his time, raise an impediment right away! It's called: "Cannot start project due to risk of delivering the wrong features! Need a product owner, stat!" And dig in your heels until you get what you need. Otherwise, the technical team is blindfolded, shooting arrows at a target with toddlers all around it. This is a big risk and probably not a pretty scene. It is up to you, the ScrumMaster, to raise impediments like this. And be courageous about it. Terminate a sprint if you have to. Call attention to it. Quantify the risks; put it in dollar signs!

Note

I recently worked with a team whose product had been in development for three years (and never once released!). The CEO was the product owner, but he was only able to attend every third or fourth demo. When he would attend, he would change everything. As a result, the product stayed in development and developers stayed grumpy; worst of all, the product remained in the incubator. What if the CEO could have invested in a product owner who could have found a way to get something to market in a year? The company could have recognized return on investment much earlier!

The physical space

It is critical for good meeting outcomes that you set up the appropriate physical space for release planning. You should aim for a space that allows team members to face each other, trade ideas, and easily capture those ideas throughout the meeting. You want them to have everything they need at their fingertips—the energy of a meeting completely crashes when someone has to run down the hall to find a white board marker or eraser! Don't let this happen to your team.

In setting up the space, think about the purpose of the meeting and the expected outcome. In which topics of conversation do you think the team will most likely engage? How can you set the room up to efficiently capture these ideas? The following figure shows some common release planning questions and statements:

Teams talk about scope, estimates, and deadlines in release planning, and they are also usually pretty vocal about risks and concerns. That means that you need to have tools to help you capture this stuff without interrupting discussions, all the while keeping the information available for the team to work with throughout the meeting. If your team is collocated (or if at least 80 percent of them are), plan to use flip charts and sticky notes. I usually arrive 30 minutes prior to the meeting to prepare the space, following this mental checklist:

• Make sure that there are enough chairs for everyone and that are they facing each other (a U-shaped conference room table is not ideal for this meeting).
• Put out Sharpie pens and sticky notes on the table—enough for everyone.
• Put flip charts on the walls to capture information and radiate any guiding information such as the Definition of Done, agenda, and ground rules (see the following figure for an example).
• Bring a notebook to capture notes and reminders during the meeting.
• If the product backlog has been captured electronically, I will have spent the afternoon the day before writing these onto sticky notes for use and manipulation by the team during the meeting.
• Review your agenda and look for opportunities for group activities.
• Open windows if possible, for natural light. Ensure that the room is at a good temperature.
• If there are a couple of remote team members, send out Skype or a similar invitation; recruit a volunteer (not a team member) to come to the meeting with a camera phone in order to stream planning artifacts and work products to the remote team members.

Definition of Done

It is imperative that the team define and agree upon the state of acceptable 'doneness' for sprints and the release during the release planning meeting. In other words, is the customer willing to accept a lower level of quality because the product is first-to-market? Or is the system life-critical and therefore absolutely no trade-offs in quality are allowed? Reaching a common Definition of Done for the release and for each sprint is imperative to set expectations and in keeping with the mind-set of build quality in. It also prevents lots of confusion during the sprint.

An example Definition of Done for a release is product features work; that is, no show-stopping defects (severity 1, 2, or 3). Page load times are less than one second. All integration tests are automated so issues are more readily and quickly found in the future. We'll discuss the sprint Definition of Done in the next section, and see Chapter 10, Scrum, Large and Small, for a nested Definition of Done concept.

Release planning output

After release planning, the ScrumMaster and product owner should decide on who will communicate the release plan, including sprint start/end dates, functionality milestones, other drops/milestones, changes in milestones, and impacts to dependencies, risks, concerns, action items, and so on. This information can be reported from a tool (if necessary) once it's been entered after the release planning event, or simply put into an Excel spreadsheet for easy consumption. Some ScrumMasters simply take a photograph of the flip chart and communicate it that way!

Here's a very simple release plan:

Write a book (release date December 15, 2012) *I'm late, by the way

Sprint 1 = chapter 1

Sprint 2 = write chapter 2, edit chapter 1

Sprint 3 = write chapter 3, edit chapter 2

…

Release sprint = final edits, graphics

Release = publish and party!

All book jokes aside, following is a visual concept of a release plan:

Another way of thinking of a release plan is as a cut line in the product backlog; the team have forecasted everything above the cut line for the release, anything below the line as not in the release.

The following image is a real release plan from a real team using flip charts and sticky notes:

Following is a product backlog that the ScrumMaster extended in order to easily show the status of items. You can see the rank, item description, and estimate—the bare minimum columns for a product backlog, plus the added planned sprint and actual sprint to record when the feature had been planned to finish versus when it really was finished. The highlighted fields for Tool Review Page, Social Media, and Google Analytics show that there was a domino effect of stories planned that slipped into the following sprint. I tallied up both estimated and actual velocities to the right, which could be used to generate a release burndown chart (see Chapter 6, The Criticality of Real-time Information).

Finally, here's a release planning timeline that shows the highest level epics (or chunks of functionality) along with approximate delivery timelines. This can be helpful for executive communication situations in which too much detail can hinder the message.