Well, it all comes down to this.

What started as a thought -- an idea -- made it through the development process to the end, and now it is time to launch the product. Everything that has been done has been leading up to this one moment -- the release.

Planning the release is the way to launch a successful product. Release planning takes place throughout the development process, with the development team and stakeholders deciding which features to release, and when. The release planning is a collaborative effort, but ultimately the product owner is responsible for making sure the correct decisions are made.

Time and Cost

The first part of planning a release is deciding how much to spend -- whether that be time, money, or functionality. None of the three can be compromised. You also must choose a launch date, which could be aligned with the product vision.

Quality is stuck

As you've learned thus far, a product's functionality evolves over time. The way the product looks and feels can also change, as can the user experience. But the quality can still be stuck in "done" mode in Scrum.

"Done" usually means that a "potentially shippable" product is available at the end of every sprint -- software that has been tested and passed all quality assurance tests. It is essential that the team deliver features that are of top quality, and that the product owner doesn't rush out the product and make quality compromises in the process. Compromising quality leaves technical debt, it damages the brand, and it leaves customers very unhappy.

Simply put, the short-term gains are worth it for the long-term growth.

Early and Frequent Releases

The Agile Manifesto states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." And it recommends, "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." These are key tenets of the Agile Manifesto, and it is the best way to get feedback from customers and users. This allows the product to evolve with the customer feedback in mind.

This can save the development team time and money, since it can save the team from implementing the wrong features, and prevent releasing a product that has either too many or too few features. A slow roll-out can develop a product that is perfect for the customer.

Releasing features frequently is a great way for customers to be able to use the product in a real environment -- and not be stuck using a demo in the sprint review meeting. It also allows the development team to reach out to more potential customers, which lessens the chance of them selecting the wrong target.

Imagine if Apple only released new software updates for the iPhone once a year? They would be inundated with problems and all the new features could be overwhelming and confusing. But instead, they release very small updates throughout the year. This way, the amount of new features is not overwhelming, and if there is a bug, it can be caught quickly and corrected.

Additionally, if the development team releases a feature that is not well received, then it gives them time to pull it back and either fix it, or cancel it entirely.

When Google initially released the Chrome browser, it didn't include the bookmark bar -- thinking it was a feature customers were not interested in. But feedback proved the customer did want the bookmark bar; so Google was able to include the bar in its next release. It was a simple fix.

Of course, frequent releases also can have their negatives. The software must be of high quality, customers must be able to download it easily, and installation should be seamless. If it is difficult to obtain the new versions, then customers will simply ignore the updates.

Releasing Quarterly

Most Agile projects are around three to six months long. If a product needs more than this, the product should be released in quarterly cycles -- with one version being released each quarter. When the Chrome browser was introduced, they released updates quarterly for the first two years. This was beneficial, because it allowed customers to continue to use and provide feedback about the product.

Velocity

You know what velocity is when it comes to speed, or to trains or physics. But velocity also applies to development teams and how quickly they complete work. Team velocity is the rate that a development team delivers tasks and stories from the product backlog. If the team knows their velocity, then they will know:

• How much value they've delivered thus far

• When they'll be able to deliver all stories in the backlog

• How many story points can be delivered by a particular date

How is velocity calculated? Again, let's use some math. A team delivers three user stories. The total story points are 20, and therefore the velocity is 20.

Next time, if the team delivers 30 story points, then the velocity is now 25 (the average of 20 and 30). Velocity is the total number of story points that a team completes during an iteration.

Velocity is needed because it can help the team:

• Predict how much work can be delivered by a particular date

• Predict a date for when a certain amount of work must be done

• Realize their limits when determining amount of time the team can commit during the sprint

There are things that can happen that can affect the team's velocity. These are:

• Roadblocks

• Motivation

• Lack of experience

• Environment of development team

• Transparency

• Project goals

• Routine processes

• Product problems

If a user story is incomplete, it cannot be counted in the velocity. Velocity is determined by work that is done and delivered. Plus:

• The team cannot determine how much is ready; it would be a guess.

• It could lead to a false sense of accuracy.

• If the story is incomplete, it provides no value to the customer.

The Release Burndown

The release burndown is the main artifact for tracking the progress of a product in Scrum. It can either be as a burndown chart or a burndown bar. Let's discuss the burndown chart first.

The Release Burndown Chart – This chart lets a team track the progress of a product. It uses the velocity from previous sprints to determine how much time is left before the release. It uses two factors: the amount of effort left in the backlog, and time. The chart is created by the ScrumMaster in the sprint review meeting once the outcome is known.

The Release Plan

An official release plan is not a requirement of Scrum, but obviously the release needs to be planned. The release plan is a rough map that guides the product to its final destination. It can forecast how the software will be received when it is released. It provides more information than the release burndown.

The plan is based on four items:

• Product backlog tasks

• Remaining effort in backlog

• Velocity

• Time

The release plan is fluid, and changes as the product backlog changes. Like the release burndown, the team in the sprint review meeting should create the release plan. The best way to form the release plan is to use a whiteboard in the team work space, so it can be visible to everyone at all times.

Releases on Large Projects

Larger products require more detailed release practices. The top three are:

• Establishing a baseline

• Look-ahead planning

• Pipelining

Establishing a baseline – When there are many teams estimating for one product backlog, the teams must be able to agree on a baseline number for their estimations and story points. Otherwise it will be incredibly difficult to know how much effort is being expended in the backlog.

If the product has several teams from the get-go, each team should have a representative that can meet to decide how they will all make estimations.

Look-ahead planning – This can be difficult, but it is necessary to help each team succeed. The team must be able to look ahead two or three sprints in the future to try to understand which backlog items will be worked on.

Pipelining - Pipelining should be considered the last choice when planning a release. Only use it if all other plans have failed. Pipelining spreads the delivery of one item on the product backlog over many sprints.

Let's use an example. Say we use two teams, Team X and Team Y. Team X has to supply a part to Team Y, and Team Y has to build with it. As an example of our look-ahead planning, we learn that it is not possible to do both pieces of work in the same sprint. We also discover it difficult to lower the amount of work by lowering the requirements even further. As a last resort, we pipeline the work. We ask Team X to use the part in the next sprint and Team Y to extend it in the subsequent one.

This sounds okay, but it presents us with a problem: How much is done once Team X has finished its work? And how can we ensure that the part will be working as expected when Team Y starts to extend it? Since partially done work never earns any points, Team X's work is not reflected in the release burndown, making it more difficult to clearly see the progress. To make things worse, feeding buffers may have to be used to ensure that Team X is indeed able to supply the component when required. A feeding buffer provides a contingency in case Team X faces more work to create the component than expected. Using feature teams, rather than component teams whenever possible, will reduce the need for pipelining.

Common Mistakes

There are some common mistakes that can be made when planning the release of the new product or feature. These are:

Not Using A Release Plan

Unengaged Product Owner

One Large Release

Compromising Quality

Not Using A Release Plan

A release plan is needed, period. Would you consider taking a long road trip without a map or GPS? Not having the release plan would do the same thing. You would end up lost. A team must always have a release burndown and a release plan, and it should be visible to everyone.

Unengaged Product Owner

One Large Release

The worst thing a team can do is release an entire software package at one time. Per Scrums manifesto, software should be released early and as frequently as possible. Shipping everything at once runs the risk of problems, and it also makes it impossible to use customer feedback to correct smaller incremental feature releases.

Compromising Quality

The product owner and team might want to release more features that necessary, and by doing so, sacrificing quality. Cutting corners doesn't work in the current software market. It makes it difficult for the development team to have pride in their work, and it shows poor engineering practices.

There is no longer a need to have a huge product launch when releasing software. That is a risky undertaking that doesn't allow a company to benefit from customer feedback. Instead, software should be released early and often, and user feedback gained, and then used in future feature releases.

Release Plan Checklist

Who is involved in the meeting?

ScrumMaster – Facilitates the Scrum meeting

Product owner – Presents a general view of the product backlog

Development team – Provides technical insights

Before the planning meeting

Before getting started, release planning needs:

• A ranked product backlog managed by the product owner

• Input from the team about overall capabilities, known velocity, and technical impacts

• High-level vision, market, and business objectives

• An acknowledgment of whether new product backlog items may be needed

Release planning checklist

• Where is your product owner? - Make sure the person responsible for making priority decisions about big features is available, whether it is an analyst, product manager, or executive.

• Do you have a ranked backlog? - These are five to 15 high-level features the product owner hopes to include in this release. Write each one on an index card.

• How will you size your items? - Establish a common baseline for sizing. Consider bringing a broad group of individuals, representing various teams, together and have them size a dozen or more product backlog items.

• Who is coming? - Everyone who is impacted by the release needs to be in this meeting to help develop the plan, identify dependencies, and commit to the release.

• Plan for logistics. - Create an agenda in advance. Consider room size. Review the agenda beforehand with ScrumMasters or team leads. Provision for breakout rooms, flip charts and sticky notes, and refreshments.

• What about multiple or distributed teams? - Consider plane tickets if planning is only four times per year. Alternatively, assign a scribe for each distributed team to enter planning information from the whiteboard into your Agile project management tool. Use breakout rooms for each team if they are all onsite.

• Do I need help? - This is an expensive and potentially large meeting. If you haven't facilitated large group meetings before, especially when multiple teams are involved, consider bringing in an experienced facilitator to help.

Materials needed

• Posted purpose and agenda

• Organizing tools: Working agreements, parking lot, communication and logistics plan, issues and concerns, dependencies and assumptions, decisions

• High touch: Flip chart or whiteboard and markers

• High tech: Projector, computer that can access needed data and tools, and a way for the computer to be shared

• Planning data

Planning data

• Results of previous iterations and releases

• Feedback from stakeholders on the product, market situation, and deadlines

• Action plans and SMART goals from prior release and retrospective

• Items and defects to consider

• Development and architecture information

• Velocity from previous iterations, or estimated

• Organizational and personal calendars

• Input from other teams and subject matter experts to manage dependencies

Output

• Release plan and commitment

• Issues, concerns, dependencies, and assumptions to be monitored

• Any new items for the release backlog

• Suggestions to improve future planning meetings

Agenda

• Opening - Welcome, review purpose and agenda, organizing tools, and business sponsor's introduction. Along with a typical opening, it is helpful for the business sponsor to share a few words on the importance of this release and the team's upcoming work.

• Product vision and road map - Remind the team of the larger picture.

• Development status, state of architecture, results of previous iterations in the prior release - Discuss any new information that may impact the plan.

• Release name and theme - Inspect current status as it relates to your road map themes, and collaboratively decide on adjustments to the name and theme to achieve a specific, current business goal for the release.

• Velocity in previous releases and iterations, or your estimated velocity - Present the velocity (if available) to be used for this release.

• Release schedule and number of iterations - Review key milestones and special events followed by a collaborative decision on timeboxes for the release and iterations within the release.

• Issues and concerns - Check in on any known issues and concerns, and record as appropriate.

• Review and update the definition of Done - Review the definition of Done and make any appropriate updates based on technology, skill, or changes in team membership since the last release.

• Stories and items from the backlog to consider - Present proposed backlog items to be considered for scheduling into this release.

• Determine sizing values - Agree upon sizing values to be used in the release planning, if velocity is unknown.

• Coarse sizing of stories intended for the release - Delivery team determines the size of items under consideration for the release, and splits items too large for iterations in the release. Product owner and subject matter experts answer clarifying questions and elaborate acceptance criteria and proper story splits. ScrumMaster facilitates collaboration.

• Close

Fanfare is not needed. Release the software; get it out, and get it right. And remember the Agile Manifesto:

Here are the 12 Agile Principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to, and within, a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -- the art of maximizing the amount of work not done -- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.