Everything you need to know about release planning in Agile

Almost everyone in software development knows the phrase “release planning.” It’s a framework meant to help all team members involved in a project – from product managers to developers. This article brings together the important information to help team members at any skill level understand and build a basic release plan for a product. Beginning with a background of the framework, you’ll walk through the thought process behind it, the individual stakeholders involved, and find details to create your own release plan. Release planning is the solid foundation on which you can build a plan to fit your goals.

What is a release plan?

A release plan in agile focuses on aligning various stakeholders while simultaneously acting as a changeable guide for releasing a product. Think of a whiteboard covered in the important details around the vision of the product. The release itself, the dates around iterations, the features and the tasks needed to create the features all provide the answers to ‘who, what, when, and why’ for a release plan. It's different, however, from planning in product increments. Increments break up a product into segments where each one can be fully built before releasing. Agile teams look at building up the features and functions gradually.

Since an agile release focuses on releasing a minimally viable product – one with just enough features to function in users’ hands – a whiteboard of the framework will be dynamic. You can cover the details for the first release and then find in a sprint that a feature deemed necessary can wait – or a feature intended for a future delivery needs to be moved up. While there are other approaches to planning releases, in the software development field, release planning in agile tends to find a spot in most teams’ product strategy.

What Isn’t a Release Plan?

A release plan is not a product roadmap – but the two are connected. A product roadmap provides a high-level overview of a release plan – or multiple release plans.

Primary purpose of release planning

The dynamic qualities help the team catch bugs in a staggered fashion with fixes to follow. This stands opposed to releasing a product in its entirety and waiting for the inevitable bugs and breaks to show up from customer feedback. By building in time and assigning stakeholders to test in alpha and/or beta groups, you can help avoid the negative feedback and potential customer alienation that comes from waiting to release a product until everything is, according to the development team, ready.

The purpose of this style of planning is also to fit into the agile approach to developing products. The agile approach is a practice of collaboration between developers, cross functional teams, and the end user. As more software products enter the market – and the market for disruption by hackers or similar builds – the agile approach to building becomes even more prevalent.

Who’s responsible for release planning in scrum?

Software developers are almost always involved in release planning in scrum. But successful release planning depends on more than just development teams. Several important stakeholders bring their own sets of skills and knowledge to the table. Which team members to include and how they are involved depends on the project. For example, customer experience leaders helping inform a new mobile banking platform won’t necessarily be on the same project as graphic designers creating a new art app.

The person responsible for release planning in Scrum is known as the product owner – sometimes called product director or value champion. The heavy lifting for this role is in balancing the many expectations, needs, and workflows of various team members.

While individuals should self-direct in order to problem-solve, an owner acts as a bridge to what team members may not be able to see. They’re looking deeply at the product and determining when to release certain aspects and how to get them in product testers’ hands.

Product managers look at the release from an even higher level than product owners. With a team in place, a manager can focus more on the execution rather than day-to-day activities that lead up to delivery.

Components of release planning in scrum

Release planning in scrum relies on collating information about various aspects of a project, starting with the release of the product. This gives the scrum team an overview from which to align their work. Under the release date for the product, there are iterations with sets of iterative release dates connected to the features for the product and the tasks needed to create each feature. Iteration planning is similar to release planning in that it can be heavily dependent on customers’ needs and the iterations that meet those needs best.

Different features become necessary or unnecessary in this process and can cause iterations and their dates to change. Through what is often multiple sprints, stakeholders come together to make decisions that will affect different components of the project. In a release planning meeting, dates can be moved, features can be added or re-prioritized, and feedback from testers can be evaluated.

Completing Your Whiteboard

With input from stakeholders, a product owner can put together the dynamic visual for release planning. One way to visualize the flow of work is to consider the structure in terms of electrical currents where direct current (DC) is starting the process on one end (features) and flowing in one direction to the release and alternating current (AC) starts the process on one end but flows back and forth. This alternating flow depends on user stories shared as feedback from developers and other stakeholders.

This feedback turns into a list of product backlog items – as does updated specifications from product managers or other stakeholders. Adjustments should fix features, re-prioritize tasks, and stage additional releases to better fit stakeholder expectations – and clear any product backlog. The flow goes wherever it is needed rather than traveling straight from one end to another. For example, the features desired may be the origination of the flow and continue up into building dates for release. But, when a feature presents a bug or the release schedule is interrupted due to date changes for sprints, the flow redirects to accommodate these shifts. The chart below shows the alternating flexible nature of release planning in agile.

Going forward

Release planning helps teams make the most of their time and their product’s potential. It cuts through the noise by organizing the timeline and aligning all stakeholders. Tailored to software development, release planning in agile takes into account the nuances of developing products to avoid missteps and missed opportunities. It’s flexible enough to fit any product and its timeline. Release planning accounts for specific tasks, important dates, and even iterations of a product to build a map for an efficient development process.