I like small releases. They provide a constant flow of shippable product increments and generate regular feedback from the end-users. If release dates are not being dictated by specific marketing events, then I like to release on a 4-week cycle with each release comprising four 1-week iterations. The logistics and overheads of releasing need to be minimised, but you should be striving for this anyway, regardless of your release frequency.
Release Planning
The purpose of release planning is to define the contents of a release or a specific shippable product increment. This involves identifying and committing to the following:
A goal for the release.
A prioritised set of user stories that will be developed in the release.
I prefer not to assign user stories to specific iterations as part of release planning. I treat the list of user stories selected for the release as a mini Product Backlog that drives iteration planning. Deciding the content of an iteration is left to the Iteration Planning Meeting where the highest priority user stories are selected from the list up to, but not exceeding, the team's velocity. (Actually it's never a simple selection based solely on value because the estimates, or cost of the user stories need to be reviewed and any risks need to be taken into consideration.)
When release planning, remember the golden rule: Don't go into too much detail.
Release planning is not a commitment to precise details. Leave that to iteration planning. Release plans are imprecise. It's only when the team starts to work on the release, will you get feedback and begin to understand how quickly progress can be made and what can be achieved. So, you don't need to understand the details of each user story, just concentrate on their key assumptions. And you don't need to provide estimates with minimum inaccuracy. Focus on understanding just enough information to commit to delivering the goal by the release date. And be prepared to revise the release plan as things move forward.
Preparing for the Release Planning Meeting
The Release Planning Meeting will run more smoothly and take less time if you're prepared. As a Scrum Master, I like to work with the Product Owner ahead of the meeting to complete the following tasks:
Define a goal for the release.
Derive a velocity for the team. The velocity is an empirical measure so basically it's the number of iterations in the release multipled by the velocity of the last iteration (assuming the team hasn't changed).
Produce a prioritised wishlist of user stories for the release by selecting those user stories from the Product Backlog that contribute to the goal. The Product Backlog is already sorted by value, so ideally the goal is a reflection of the highest value user stories found at the top of the Product Backlog. Typically the user stories would've been written previously by the Product Owner as part of the evolution and management of the Product Backlog.
Time permitting, have some developers preview the wishlist to ensure they understand the gist of the user stories. Have them review the estimates to ensure they're sensible and provide any estimates that are missing. Given the granularity of the user stories, these estimates are coarse so donât worry about them. At this early stage their purpose is to help size the wishlist to approximate the team's velocity. They'll be revisited in the Release Planning Meeting. The Product Owner should be prepared to split any user stories that the developers have difficulty understanding or estimating. Indeed it may be necessary for the developers to conduct a spike in order to provide an estimate.
Review the wishlist. The Product Owner can add some of the next highest value user stories from the Product Backlog or remove some of the lowest value user stories from the wishlist until the total estimate approximates the team's velocity. The Product Owner should be happy with the user stories in the wishlist and their priorities, and should note any questions relating to the estimates that he wishes to raise in the Release Planning Meeting.
Release Planning Meeting
The purpose of the Release Planning Meeting is to have everyone in the team understand and commit to delivering the agreed release by the agreed date. Those present at a Release Planning Meeting include the Product Owner plus any other stakeholders that can add valuable input, the developers and testers, and the Scrum Master.
The Release Planning Meeting takes the following route:
The Product Owner explains the release goal to the team. When the team understands the motivation behind the release goal (and the release date, if it's governed by some external event), they're placed in a better position to help identify the scope that has the best chance of being completed by the release date.
The developers provide their team's velocity. If the team hasn't changed, the velocity should be the number of iterations in the release multipled by the velocity of the last iteration.
The developers ask enough questions about the user stories to be able to confirm the existing coarse estimates or provide new ones. This interaction may require the Product Owner to split some user stories, and when there's some technical-unknown, the user story should be split to include a spike.
The developers assess the technical risk for each user story and provide some classification, e.g. high, medium or low.
Given the release goal and taking the values, estimates or costs, and risks into consideration, the Product Owner selects the user stories from the wishlist to make up the release plan.
Consensus needs to be reached on the release plan with everyone present stating their commitment verbally.
There are plenty of opportunities in the Release Planning Meeting to get bogged down, so it's important to remain focused and to maintain a brisk pace. I like to time-box each activity and use an egg timer.
Previous Topic
