While they work iteratively in sprints, Scrum teams focus on releases rather than on projects. What is a release? Perhaps it is easiest to say that a release occurs when the development team gives working software to someone outside of the team to use for its intended purpose. It is not a release when you give something to the downstream QA validation group for testing and it’s not a release when you integrate your software with that of other development teams. It’s a release when you say to somebody, “Here, go use this.” Releases are usually the result of multiple sprints of concentrated development effort, and they often mark a moment of market or business or customer impact.
While it is certainly possible for a team (or teams) to build and release software without doing anything more complicated than regular sprint planning and backlog grooming, it is often that case that a release has its own set of considerations and complications that go beyond the things the team is concerned with while they develop the software. For this reason, doing a release often requires more comprehensive planning with a wider perspective than the typical Scrum team will provide.
Release planning in Scrum is an Agile approach to creating the wider view that is often necessary to take a release to market successfully. Release planning fits nicely into the planning frameworks that are often offered for Scrum. For instance, I am most familiar with the five level model of Agile planning:
As always when we talk about any kind of planning in an Agile context, we must be careful to keep our approach iterative (and not restrictive) and to support self-organizing teams and empirical process control. How can we “plan” a release and at the same time avoid the disadvantages associated with up front planning? The answer is very simple: Use the plan for insight and not direction, and update the plan at least each iteration.
How does Release Planning support Agile principles?
- Breaking down barriers – The business and stakeholders and developers all plan together.
- Interactions between people - In Scrum, when we do Release Planning, we get all of the people who are involved into a room so they can interact.
- Iterative and incremental – In Scrum, we do everything iteratively and incrementally. We do Release Planning once (usually near the beginning of the release development), and then again and again as needed.
- The purpose of release planning in Scrum is to make visible as much as is known about the desired release. Its purpose is not to make commitments.
- An Agile Release Plan increases in accuracy over time as the results of each iteration are incorporated into it.
The Release Planning Ceremony
Agile release planning is best accomplished via the straightforward method of getting everyone into a room together. Everybody who will be involved in the release should participate in the planning. That gives us a potential invite list that looks like this:
- Scrum Master
- Product Owner
- Delivery Team
- Outside experts
- 3rd Party Vendors
When all of these people gather and work together on the release, marvelous things can happen.
A Release Planning agenda might look like this:
- Goals of the release (PO)
- Background, business and competitive climate (PO)
- Current product and development state (PO)
- Grooming of Product Backlog for release (All)
- Capture and discussion of issues (All)
Technical Issues (Dev teams)
- Testing Challenges and Strategies
- Engineering Standards and Practices
- Hardening and Hackathon
- Continuous integration
Team interactions (Dev teams)
- Scrum of Scrums
- Special handling of multi-team Sprint Planning, Sprint Reviews
- Multi-team retrospectives
- Tentative schedule (PO)
Finally, here are a few tips to make your release planning activities effective:
- Do as little planning as is necessary.
- Start release planning when you realize you need it, even if it’s near the end of the release effort.
- Plan using stickies on the walls. If you must transcribe them into an online tool, do that later, after the meeting.
- Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen. Release planning is not about committing to a list of features to be released on a certain date.
- Include vendors and other third parties who are relevant and involved in your release planning meeting.
- Revisit the release plan after each sprint and update it.
- Don’t give in to the urge to publish a release plan as a separate document
- There’s no prescribed timebox for release planning because it will vary with the size of the team and the expected length of the release effort.
Release Planning can take more or less time based on a number of variables including the size of the project team, number of stakeholders, level of agreement on objectives, and experience level of the teams and facilitator. At first you might spend a half day planning an eight week release for two scrum teams and a few stakeholders. With practice, one hundred well-facilitated and prepared people can plan an 8 week (4 sprint) release in one day. Such a meeting might include a handful of development teams with their Product Owners and ScrumMasters, some outside customers, stakeholders and more.