Instead, see:

Who likes long meetings? As a Scrum Coach, I ask this question of teams new to Scrum. I ask it mostly in jest, but also as a inoculation against people who will inevitably complain about lengthy Scrum meetings. Obviously I turn it around on them. “I hate long meetings too, why do you think we have such long meetings? What could we do better?” Sprint Planning and Sprint Retrospective meetings can drag on and on and on unless they’re executed well. In addition, the ROI or value of these meetings can be horrible if they are not well structured. The meeting I want to focus on today is the Sprint Planning Meeting.

One of the best ways I’ve found to greatly increase the value of sprint planning meetings is to hold what I call a “Sprint Preview Meeting.” Others call it a Sprint Pre-Planning meeting, and still others call it a “backlog grooming session”. I don’t like those other names for various reasons, but let’s not get hung up on nomenclature, shall we? I’m assuming a 2 week sprint cycle here, but you can tailor it to your needs as well.

In case you are wondering, the Scrum Guide is very clear on this issue — up to 10% of the team’s time in a sprint can be spent preparing for the next sprint. The teams I have coached have had great success with having preview meetings PRIOR to a sprint.

The optimum time I’ve found for the preview meeting for the next sprint is the latest time in the current sprint that does not interfere with the “home stretch” of that current sprint. In other words, about 70% of the way through the current sprint is optimum. There are numerous reasons behind this rule of thumb (some of which you will see below), but I won’t go into detail on that now. Let’s keep our eye on the “sprint goal” of this article, my friend.

The preview meeting is run just like the first part of any normal Sprint Planning Meeting. The Product Owner presents the backlog items, and the team estimates them. One important note here is that a backlog item is always open for re-estimation until it is accepted into a particular sprint. As such, if some information changes about a backlog item between the preview meeting and the planning meeting, the team is allowed to re-estimate if they so desire. The same goes for re-prioritizing backlog items between the preview meeting and the planning meeting. We’ve found this to happen in only about 5% of the cases, so it’s not a big risk. Besides, you’d rather it happen a few days before the next sprint than a few minutes *into* the next sprint! The goal of the meeting is to come out with sprint sized estimates for enough work to represent about 1.5-2 sprints. A sprint sized estimate simply means that the backlog item is small enough to fit into a single sprint. In addition, it would be ideal if these backlog items were fully fleshed out(details, acceptance tests, etc) and ready enough to be accepted into a sprint on a moment’s notice.

Having met your sprint preview goal with flying colors, the only thing really remaining to do in the planning meeting is to task out the backlog items and decide which items will be accepted into this sprint.

Below are some of the other advantages and disadvantages of preview meetings as my teams have experienced them.

Advantages

More time before the sprint actually starts for the new backlog items to “sink in” before estimating and working them.

More time before the sprint actually starts to research/bone up on any technology hurdles.

More time before the sprint actually starts to optimize design, test, etc (i.e. team members pondering the issue for a few days before the sprint begins).

More time before the sprint actually starts to research/bone up on requirement hurdles. Things like requirement holes, validating acceptance tests, etc.

Forces the Product Owner to be well prepared for the next sprint. Granted, many of my experiences have been with newbie product owners, or at least people new to Scrum. I’m guessing that’s a pretty common problem though. Many of my experiences both inside and outside of Scrum have been on teams where requirements were a main factor in productivity levels being low. I think there’s some study out there about how requirements are the bain of development existence. I’ll leave verification of that up to you as a homework assignment.

Introduces new backlog items in a time in the sprint when the team (or just some members)might be currently running out of productive work in the current sprint — so this allows them to punch out a small extra backlog item late in the current sprint, OR get started on a tasty one that is upcoming.

If the Product Owner discovers something in presenting new items that inclines them to re-prioritize, they have a couple of days to get that figured out. (re-prioritize, queue up new items instead, etc)

Disadvantages

If the Product Owner discovers something in presenting new stories that inclines them to re-prioritize, the team might feel like time was wasted or feel stressed due to the change. As I said above, though, we want to know this a few days before the next sprint, not a few minutes IN to the next sprint.

It can be hard for some team members to “switch gears” at a time when they’re rockin and rolling on sprint N, to start thinking about sprint N+1. This is why doing the preview about 70% of the way through the current sprint is important. The team will still have a few days to continue to rock and roll and bring the current sprint to a close. Trying to do a preview on the last day or two of the sprint is probably a recipe for disaster.

It can take a while to get used to this type of cycle, but all of the teams I worked with liked it much better than a sprint planning meeting that dragged on and on or didn’t provide enough value to the team.

So, as you can see, there is much ROI to be gained by doing Sprint Preview Meetings. If your planning meetings are unfulfilling, I highly encourage you to give it a shot. Be sure to ‘inspect and adapt’ it to your team of course. If you’d like some tips on good practices when executing a Sprint Preview meeting, see this post.

I’d be interested in any comments you might have, so feel free to leave them below.

6 Responses

Interesting idea; I have a question
What was meant by “sprint sized” in the following:
“The goal of the meeting is to come out with sprint sized estimates for enough work to represent about 1.5 sprints.”

A “sprint sized” story is a story that is at or below the maximum allowed size for a story to be in a single sprint. I believe the rule of thumb there is that a sprint sized story should be no larger than what one developer can do in one sprint, if that developer was working full time on that story only.

If a story “won’t fit in a sprint”, then it should be split or edited so that it will fit into a single sprint.

The goal of the meeting is to come out with sprint sized estimates for enough work to represent about 1.5-2 sprints. A sprint sized estimate simply means that the backlog item is small enough to fit into a single sprint. In addition, it would be ideal if these backlog items were fully fleshed out(details, acceptance tests, etc) and ready enough to be accepted into a sprint on a moment’s notice.

I agree that some type of prep meeting is essential to making the iteration planning meetings go smoothly. We do this the Friday before sprint planning but it is limited to the Product Owner, ScrumMaster and Engineering Manager. We also do mid-iteration Story Pointing to try to make sure that there is always ready work at the top of the backlog ass you mention. Great advice!

[…] for a Good Sprint Preview Meeting (aka Product Backlog Grooming) By charlesbradley In my previous post, I make the case for doing a Sprint Preview Meeting, which is really just a special form of product […]