Most software projects will do best with a new release every two to six months. Certain website projects may release even more frequently, but even then there is a benefit to collecting related new features into a release. It is frequently useful to start release planning from a product development roadmap showing the main areas of focus for the next handful of new releases. This product development roadmap will certainly change—and we want it to since the changes will be the result of our learning more about our product, its market, and our ability to develop the product.

Release planning is longer-term planning that enables us to answer questions like “When will we be done?” or “Which features can I get by the end of the year?” or “How much will this cost?” Release planning must balance customer value and overall quality against the constraints of scope, schedule, and budget.

Every organization must determine the proper cadence for releasing features to its customers. 

Though the output of a sprint is potentially shippable, many organizations choose not to release new features after every sprint. Instead, they combine the results of multiple sprints into one release.

When is it required to release a product?

If a team can start release planning with a range of acceptable dates they will have more flexibility in timing releases. For example, starting with a date range in mind enables a team to make statements like “After six or seven iterations we should have the minimum functionality and maybe ten to twelve before we have everything on the 1.0 wish list.” 

In some cases the date truly is fixed. Most commonly this occurs when preparing a release for a trade show, a key customer release, or some similar milestone. If this is the case, release planning is actually a bit easier as there are fewer variables to consider. However, the decisions about which stories to include will usually be more difficult. 

Some organizations match the release cadence to the sprint cadence. In such cases, the organization releases the potentially shippable product increment created during that sprint at the end of each sprint.

Some organizations don’t even wait for the sprint to end; they release each feature as it is completed, a practice often referred to as continuous deployment (or continuous delivery). Such organizations release a feature or a change to a feature to some or all of their customers as soon as the feature is available, which might be as often as several times a day.

Whether the organization intends to deploy every sprint, every few sprints, or continuously, most organizations find some amount of longer-term, higher-level planning to be useful. I refer to this type of planning as release planning. If the term release planning seems inappropriate to your context, replace the term with one that is better suited. Synonyms I have heard different organizations use include:

• Longer-term planning—connoting that the goal is to look at a horizon that is greater than a single sprint,

• Milestone-driven planning—because releases tend to align with significant milestones, such as an important user conference or the completion of a minimum set of features for a viable, marketable release

What to release?

In order to plan a release, the customer must prioritize the requirements (or stories). Prioritizing requirements into the familiar high, medium and low categories is useful but can lead to tedious arguments over what constitutes a high priority story as opposed to a medium priority story. Fortunately, we can borrow a MoSCoW technique. MoSCoW technique includes a prioritization technique referred to as the MoSCoW rules. MoSCoW is an acronym for 

  • Must have 
  • Should have 
  • Could have 
  • Won’t have this time 

The must-have features are those that are fundamental to the system. Should-have features are important but there’s a short-term workaround for them. If the project has no time constraints, the should-have features would normally be considered mandatory. Could-have features are ones that can be left out of the release if time runs out. Features prioritized as won’t-have are ones that are desired but acknowledged as needing to come in a later release. 

The inputs to release planning include outputs from product planning, such as the product vision, high-level product backlog, and product roadmap. We also need the velocity of the team or teams that will work on the release. For an existing team, we use the team’s known velocity; otherwise, we forecast the team’s velocity during release planning.

One activity that recurs in release planning is to confirm the release constraints of scope, date, and budget and to review them to see if any changes should be made, given the passage of time and what we now know about the product and this release.

Another activity of release planning is product backlog grooming, which includes creating, estimating, and prioritizing more detailed product backlog items from high-level product backlog items. These activities could occur at multiple points in time:

• After product planning but before initial release planning

• As part of the initial release-planning activity

• During each sprint as necessary.

Each release should have a well-defined set of minimum releasable features (MRFs). The initial MRFs for a release might have been defined during envisioning. Even so, during release planning, we always review the MRFs to ensure that they truly do represent the minimum viable product from the customers’ perspective.

During release planning many organizations also produce a sprint map, indicating in which sprint some or many of the product backlog items might be created. A sprint map isn’t intended to project too far into the future. Instead, a sprint map is useful for visualizing the near-term future to help us better manage our team’s own dependencies and resource constraints, as well as coordinate the efforts of multiple collaborating teams.

The outputs of release planning are collectively referred to as the release plan. The release plan communicates, to the level of accuracy that is reasonable given where we are in the development effort when we will finish, what features we will get, and what the cost will be. This plan also communicates a clear understanding of the desired MRFs for the release. Finally, it frequently will show how some of the product backlog items map to sprints within the release.

Communicating: An important aspect of release planning is communicating progress. Although any highly visible way of communicating progress can be used, most teams use some form of burndown and/or burnup chart as their principal information radiator of release status. Let’s look at how to communicate release status on both fixed-scope and fixed-date releases.

Communicating Progress on a Fixed-Scope Release: On a fixed-scope release we have an idea of the total scope of work we wish to achieve. The goal is to communicate how we are progressing toward completing that work.

Fixed-Scope-Release Burndown Chart: A burndown chart for a fixed-scope release shows the total amount of unfinished work that remains each sprint to achieve the current release goal. In this type of chart, the vertical axis numbers are in the same units we use to size our product backlog items (typically story points or ideal days). The horizontal axis represents sprints

At the end of each sprint, we update this chart to show the total amount of work remaining within the release. The difference between the amount of work remaining at the beginning of a sprint and the work remaining at the end of the sprint represents the sprint velocity. This is plotted as the “Actual” line.

Fixed-Scope-Release Burnup Chart: A burnup chart for a fixed-scope release shows the total amount of work in a release as a goal or target line and our progress each sprint toward achieving that goal. The horizontal and vertical dimensions of the chart are identical to those of the release burndown chart.

You may also like