Release Planning (Longer-Term Planning): Chapter 18
Innolution offers customized Agile release planning (longer-term planning) training. Contact us for more details
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. This chapter discusses how release planning fits into the Scrum framework and how to perform release planning on both fixed-date and fixed-scope releases.
Release Planning in Scrum: An Overview
Every agile organization must determine its own cadence for releasing features to its customers. Some choose to release every sprint. Others group the results of multiple sprints into one release. Still others release as soon as each feature is completed, a practice often referred to as continuous deployment or continuous delivery. Whichever cadence an organization chooses, most find some amount of longer-term, release planning to be useful.
If the term release planning doesn’t fit well with your organization’s practices, replace the terminology with longer-term planning or milestone-driven planning. Whatever you choose to call it, release planning in Scrum targets a future state when important variables such as date, scope, and budget need to be balanced. The basic timing, participants, and process remain the same regardless of the name.
Release Planning in Scrum Overview: Timing & Purpose
Release planning in Scrum happens every sprint, either as part of the sprint review or in the normal course of preparing for the subsequent sprint.
Initial release planning takes place following envisioning / product planning and typically lasts a day or two. The initial release plan will not be too complete or too precise because agile organizations understand that the release plan will be updated with validated learning every sprint.
Recall that purpose of product planning is to envision what the product should be; the purpose of release planning in Scrum, then, is to determine the next logical step toward achieving the product vision.
Release Planning in Scrum Overview: Participants
Release planning in Scrum involves collaboration between the stakeholders and the full Scrum team. Each person’s exact involvement may vary over time.
Release Planning in Scrum Overview: Process
The image shown below illustrates release planning in Scrum.
The inputs for release planning include the Scrum development team’s velocity range as well as the outputs of envisioning: product vision, high-level product backlog, and optionally the product roadmap. The velocity can either be a forecast (in the case of a new team) or historical (in the case of an existing team). See “Estimation and Velocity in Scrum: Chapter 7” for more on velocity metrics.
The outputs of release planning, which are detailed later in the chapter, are collectively known as the release plan.
Release planning in Scrum consists of several activities:
- Review and update the release constraints of scope, date, and budget.
- Product backlog grooming.
- Review and update the minimum releasable features (MRFs)
- Product a sprint map (optional)
The activities can take place at multiple points in time, including immediately after product planning, as part of the initial-release planning activity, and during each sprint. These release planning activities will be discussed in greater detail in the sections that follow, beginning with the release constraints.
Release Planning in Scrum: Constraints
The goal of Scrum release planning is to determine the most valuable next release and the desired level of quality. The release constraints of scope, date, and budget are important variables that affect how organizations achieve that goal. One or more of these constraints will probably be established as fixed during envisioning, with the remaining constraint(s) left flexible. For example, a fixed-date release has a set release date that must be met; the scope (and possibly the budget), however, are flexible.
Scrum Release Planning Constraints: Fixed Everything
Historically, plan-driven predictive development approaches assumed that all three constraints could and should be fixed. These approaches assumed that the upfront plan could account for all requirements and as such, the scope would not change. With the scope fixed, it was then relatively easy to estimate a fixed cost and schedule. The problem is these “fixed-everything” upfront plans are almost always wrong. That’s why Scrum release planning requires that at least one of the variables (scope, budget, date) be flexible.
Scrum Release Planning Constraints: Fixed Scope and Date
Another suboptimal approach to Scrum release planning is to fix both the scope and date, but let the budget be flexible. This approach suffers from a number of issues:
- It’s difficult to increase budgets once development has begun.
- It’s almost impossible to lock down these two variables at once. When push comes to shove, one of them will give.
- It assumes that applying more resources will help teams accomplish more in less time. This is only infrequently true, and even then, only up until a point.
Scrum Release Planning Constraints: Fixed Scope
A fixed-scope model to Scrum release planning is appropriate when the feature set is truly more important than the schedule. In this model, the release date is moved out until the full scope is complete. Because the end date is a moving target, budget can’t really be fixed—People expect to be paid for their work!
One problem with a fixed scope approach is that in an organization with multiple teams or departments working on one project, a moving date makes coordination extremely challenging.
Another problem is that a fixed-scope approach is often an indication that the scope of the release is too large. A better solution might be to release smaller feature sets more often.
Scrum Release Planning Constraints: Fixed Date
A fixed date approach to Scrum release planning, in which the date and budget are fixed but the scope is flexible, is the approach most closely aligned with Scrum principles. Because the highest priority features are being developed and completed first, any features that don’t make it into the first release are less valuable, which makes it easier to release the product as scheduled. A fixed-date approach also aligns well with Scrum’s emphasis on timeboxing—prioritization is essential to making the model work.
The fixed-date model is even easier to use if the set of minimum releasable features (MRFs) is truly small. That means that any features that are beyond the scope of the MRFs are only nice-to-have, not must-have, features.
Read “Scope is the Antifragile Degree of Freedom” for an indepth look at how much more robust your development effort can be when you choose the correct combination of constraints.
Scrum Release Planning Constraints: Variable Quality
Scrum release planning is all about balance. If an organization overly constrains scope, date, and budget, the flexible variable becomes quality. Poor quality either results in a solution that doesn’t meet customer expectations or one that is overly burdened with technical debt. Read “Chapter 8: Technical Debt” for a more indepth discussion on technical debt.
Scrum Release Planning: Updating Constraints
An important component of Scrum release planning is to revisit the constraints to see if they should be rebalanced in light of the realities of the development effort. Sometimes this means dropping lower value features from the MRFs, or narrowing the focus of the release so that the set of MRFs can be smaller. In certain instances, it might mean adding more people to the effort (effectively increasing the budget). And sometimes it means that the date simply cannot be met no matter what, in which case the advisability of continuing the project in its current form would certainly be in doubt. These tradeoffs and decisions must be made, revisited, and remade continuously during a Scrum development effort.
Release Planning in Scrum: Product Backlog Grooming / Refinement
One of the inputs to release planning in Scrum is a high-level product backlog, filled with big picture, epic-sized product backlog items(PBIs), that was created during envisioning. These PBIs are too large and do not contain enough details for release planning. As a result, many organizations do product backlog grooming (aka product backlog refinement) as part of release planning or even as a separate workshop preceding release planning.
During product backlog grooming, the participants create smaller, more manageable PBIs that the team can estimate and the product owner can prioritize. They do not need to do this for every PBI in the product backlog; some of the PBIs can remain at the epic level until it is time to fit them into a release. As the development effort progresses, this grooming activity happens repeatedly as existing PBIs rise in priority or new PBIs are added to the product backlog.
The product backlog and product backlog grooming are covered in much greater detail in “Product Backlogs in Scrum: Chapter 6.” You might also want to brush up on the product backlogs by reading “Demystifying Product Backlog Concepts.” You can also read the blog series on all of the Scrum practices, beginning with “What Is Product Backlog Grooming and How Long Should It Take?”
Release Planning in Scrum: Refine Minimum Releasable Features (MRFs)
The minimum releasable features (MRFs) represent the smallest set of ”must-have” features—the ones that simply have to be in the release if the organization is going to meet customer value and quality expectations. An important activity during release planning in Scrum is to reevaluate and refine the MRFs to only include those that are truly necessary, based on the fast feedback and validated learning acquired during sprints. The set of MRFs will also need to be reviewed after the PBI estimation activity that happens during product backlog grooming. If, on closer inspection, the MRFs do not seem economically viable, it might be time to pivot or terminate the project.
Refer to “Envisioning (Planning) in Scrum: Chapter 17” or “MVP, MMF, and MRF, Oh My!” to better understand MRFs.
Release Planning in Scrum: Sprint Mapping (PBI Slotting)
Though the precise set of product backlog items (PBIs) for a particular sprint are not chosen until sprint planning, a rough approximation of which PBIs might be completed during the near-term sprints can be very helpful for release planning in Scrum. This approximation is often referred to as sprint mapping or PBI slotting.
To create a sprint map, the Scrum team needs an appropriately detailed, estimated, and prioritized product backlog, which should be the output of the product backlog grooming activity. Using the Scrum development team’s velocity (either historic or estimated), the team can quickly approximate a set of PBIs for each sprint by grouping together items whose aggregate size is roughly equals the team’s average velocity. This mapping should follow the priority as closely as is practical.
Though they are not valuable for every organization, sprint maps do have the following benefits:
- Give a rough idea of when certain features within the release will be created.
- Give insight into how to structure the product backlog in more natural or efficient ways.
- Allow visibility into inter-team dependencies.
- Facilitate rolling, look-ahead planning activities.
Sprint maps evolve during the development effort. Ultimately the decision as to which items to bring into the sprint will be made at the last responsible moment—the sprint planning for that sprint. You can read more about sprint maps in “Agile Risk Management: Managing Risk Via the Product Backlog.”
Fixed-Date Release Planning in Scrum
Read the blog “Fixed-Date Release Planning in Scrum” to learn the six steps of fixed-date release planning in Scrum.
FIXED-SCOPE RELEASE PLANNING IN SCRUM
Read the blog “Fixed-Scope Release Planning in Scrum” to learn the five steps of fixed-scope release planning in Scrum.
Release Planning in Scrum: Calculating Cost
Calculating costs on either a fixed-date or fixed-scope release is easy. Assume the factors will not change during the release.
- Determine who is on the team.
- Determine the sprint length, in hours or days.
- Multiply personnel cost (per hour or per day) by sprint length to get a cost per sprint.
- For a fixed-date release, multiply the number of sprints by the cost per sprint.
- For a fixed-scope release, multiply both the high and low number of sprints by the cost per sprint.
Release Planning in Scrum: Communicating
An important aspect of release planning is to communicate progress. Although any highly visible way of communicating progress is appropriate, many teams use some form of burndown and/or burnup chart as the principal information radiator of release status. Learn more by reading the blog “Burn Charts for Communicating Progress Through a Scrum Release.”
Release Planning in Scrum: Closing
This chapter was focused on release planning in Scrum. “Sprint Planning in Scrum: Chapter 19” will discuss the next level of planning in Scrum: sprint planning.
If your organization wants to improve at release planning or product backlog management, consider training from Innolution. Innolution's Certified Scrum Product Owner (CSPO) training deal with these concepts in depth. Our Certified ScrumMaster (CSM) class also covers release planning.