Do you want to reduce the risk and uncertainties associated with software development? Do you think you need to start making better decisions during development?… Then! you need to understand the concept of Release Planning and how to write a good Release Plan.


Release Planning is more than the administrative process of releases or “selecting an optimal subset of requirements for realization in a certain release” (Carlshamre, 2002) . It also involves translating the roadmap into requirements to be developed, deciding on what and what not to develop and communication and negotiation to resolve conflicts between stakeholders.

A Release Plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.


Release Planning is a collaborative effort involving these roles:

  1. Scrum Master — Facilitates the meeting
  2. Product Owner — Represents a general view of the product backlog
  3. Delivery team or Agile team — Provide insights into technical feasibilities and dependencies
  4. Stakeholders — Acts as trusted advisors as decisions are made around the release plan


Release Planning is the second practice during Planning, Release planning immediately follows after the ‘Vision’ of the project have been clearly identified and documented.

Release Planning encourages working on one project at a time because, many teams working on several projects simultaneously can be a very fatal mistake. In fact Task-switching has a substantial cost: “The 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, which increases the total value of your work.

While working on one project at a time, it is also advisable to release early and often. If you group your most valuable features together and release them first, you can achieve startling improvements in value.

Releasing early and often doesn’t mean setting aggressive deadlines. In fact according to McConnell [1996] (p. 220) aggressive deadlines extend schedules rather than reducing them. Instead, release more often by including less in each release.

To be able to release early and often and still deliver value involves an adept understanding of MMF’s (Minimum Marketable Features). 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 provide value in many ways, such as competitive differentiation, revenue generation, and cost savings. The minimum in MMF means you should 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 [James Shore & Shane Warden].

There are two basic types of plans:

  1. Scope-boxed Plans: defines the features the team will build in advance but the release date is uncertain.
  2. Time-boxed Plans: defines the release date in advance but the specific features the release will include are uncertain

Time-boxed 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 time-box, your plan will include more low-value features.

To create your time-boxed plan, first choose your release dates. Then schedule releases at regular intervals, such as once per month and no more than three months apart. Now pick out your plan while considering the project vision to guide you in brainstorming MMF’s. 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.

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. 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.

NB: Release Planning should be done in such a way that releases can be made at any time! Yes! any time. the point is not to actually release all the time, but to enable you to release at any time. This 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 [James Shore & Shane Warden].


  • It gives the team a common vision about what needs to be achieved, and when.
  • It guides the team to make decisions during detailed planning.
  • It helps prioritize the stories.
  • It resolves conflicts and guides the team(s) toward the right balance on trade-offs.
  • Frequent releases are good for organization.
  • By delivering tested, working, valuable software to your stakeholders regularly, you increase trust. Your stakeholders request a feature and soon see results.
  • You will also get feedback from stakeholders more quickly. This allows you to learn and adapt.
  • Generally, life is much better with a release plan.
Release Incrementally considering MMF’s, Team Velocity $ Stakeholders.