Starting the Next Sprint and Release Planning in Scrum

Starting the Next Sprint

Following the Sprint Review Meeting, the Product Owner takes all the input, as well as all new priorities that have appeared during the Sprint, and incorporates them into the Product Backlog; new items are added, and existing ones are modified, reordered, or deleted. Once this updating of the Product Backlog is complete, the cycle is ready to begin all over again, with the next Sprint Planning Meeting.

One practice many teams find useful is to hold a Prioritization Meeting toward the end of each Sprint, to review the Product Backlog for the upcoming Sprint with the Product Owner. In addition to giving the team an opportunity to suggest items the Product Owner may not be aware of – technical maintenance, for example – this meeting also kicks off any preliminary thinking that’s required before the Sprint Planning Meeting.

There’s no downtime between Sprints – teams will often go from a Sprint Review one afternoon into the next Sprint Planning Meeting the following morning. One of the values of Agile development is “sustainable pace”, and only by working regular hours at a reasonable level of intensity can teams continue this cycle indefinitely.

Release Planning

Sprints continue until the Product Owner decides the product is almost ready for release, at which point there may be a “Release Sprint” to do final integration and testing in preparation for launch. If the team has followed good development practices along the way, with continuous refactoring and integration, and effective testing during each Sprint, there should be little pre-release stabilization required.

A question that’s sometimes asked is how, in an iterative model, long-term release planning takes place. At the beginning of a project the team will do high-level release planning; since they cannot possibly know everything up front, the focus is on creating a rough plan to give the project broad direction, and clarify how tradeoff decisions will be made (scope versus schedule, for example). Think of this as the roadmap guiding you towards your final destination; which exact roads you take and the decisions you make during the journey may be determined en route.

Sprint Retrospective in Scrum

Following the Sprint Review, the team gets together for the Sprint Retrospective. This is a practice that some teams skip, and that’s unfortunate, because it’s the main mechanism for taking the visibility that Scrum provides into areas of potential improvement, and turning it into results. It’s an opportunity for the team to discuss what’s working and what’s not working, and agree on changes to try. The Scrum Team, the Product Owner, and the ScrumMaster will all attend, and a neutral outsider will facilitate the meeting; a good approach is for ScrumMasters to facilitate each others’ retrospectives, which enables cross-pollination among teams.

A simple way to structure the Sprint Retrospective is to draw two columns on a whiteboard, labeled “What’s Working Well” and “What Could Work Better” – and then go around the room, with each person adding one or more items to either list. As items are repeated, check- marks are added next to them, so the common items become clear. Then the team looks for underlying causes, and agrees on a small number of changes to try in the upcoming Sprint, along with a commitment to review the results at the next Sprint Retrospective.

A very useful practice at the end of the Retrospective is for the team to label each of the items in each column with either a “C” if it is caused by Scrum (in other words, without Scrum it would not be happening), or an “E” if it is exposed by Scrum (in other words, it would be happening with or without Scrum, but Scrum makes it known to the team), or a “U” if it’s unrelated to Scrum (like the weather). The team may find a lot of C’s on the “What’s Working” side of the board, and a lot of E’s on the “What’s Not Working”; this is good news, even if the “What’s Not Working” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.

Sprint Planning Meeting

At the beginning of each Sprint, the Sprint Planning Meeting takes place.
In the first part of the Sprint Planning Meeting, the Product Owner and Scrum Team (with facilitation from the ScrumMaster) review the Product Backlog, discussing the goals and context for the items on the Product Backlog, and providing the Scrum Team with insight into the Product Owner’s thinking.
In the second part of the meeting, the Scrum Team selects the items from the Product Backlog to commit to complete by the end of the Sprint, starting at the top of the Product Backlog (in others words, starting with the items that are the highest business value for the Product Owner) and working down the list in order. This is one of the key practices in Scrum: the team decides how much work they will commit to complete, rather than having it assigned to them by the Product Owner. This makes for a much more reliable commitment; first, because the team is making it, rather than having it “made” for them by someone else; and second, because the team itself is determining how much work will be required, rather than having someone else decide how much “should” be required. While the Product Owner doesn’t have any control over how much the team commits to, he or she knows that the items the team is committing to are drawn from the top of the Product Backlog – in other words, the items that he or she has rated as most important. The team does have the ability to pull in items from further down the list if it makes sense (for example, pulling in a slightly lower priority item that can be quickly completed as part of higher priority work).
The Sprint Planning Meeting will often last a number of hours – the team is making a very serious commitment to complete the work, and this commitment requires careful thought to be successful. The team will begin the Sprint Planning Meeting by estimating how much time each member has for Sprint-related work – in other words, their average workday minus the time they spend attending meetings, doing email, taking lunch breaks, and so on. For most people this works out to 4-6 hours of time per day available for Sprint-related work.