Tips for ScrumMasters: Estimate user stories outside Sprint Planning Meetings

One of the biggest strengths of Scrum is that it is a framework instead of a detailed methodology such as RUP. In Scrum, concepts are described that make essential aspects of projects fall into place in a very powerful way. One does not need a Process Engineer to tailor Scrum before it can be applied successfully. However, because there are many things that Scrum does not describe in detail, there is plenty of room left to mess things up 🙂
In this blog, I discuss on how to facilitate the estimation of Product Backlog items so that the Product Owner can do release planning.

As Mike Cohn has pointed out in his excellent book Agile Estimating and Planning, planning is done at three levels in Agile projects:

• Daily planning;
• Iteration planning;
• Release planning.

In most Scrum projects, the first two of these levels get the attention they deserve: Daily planning is done at the Daily Scrum, Iteration planning is done at the Sprint Planning Meeting. The third level of planning is where things often get messier. In most projects, there is a need for a planning horizon that is further away than one Sprint. For example, a marketing campaign is planned three months from now and the Product Owner wants to know what features can be expected to be done by then. If the project uses user stories with story point estimates, the following information is needed:

• The velocity of the team(s): how many story points are done each Sprint?
• Estimates in story points for at least all user stories that have a chance of being done before the release date.

I have seen that people struggle with this because Scrum has traditionally not been explicit on when and how to establish estimates for user stories. In many Scrum projects, the only time when estimating is done is the Sprint Planning Meeting. Sometimes user stories are estimated in story points, but these estimates are given only to the same set of user stories for which tasks are identified and estimated subsequently. This really defies the purpose of story point estimates. The team might as well omit story point estimates altogether because the task estimates should be enough to check if it is viable to do the planned work in one Sprint.
My advice is to estimate user stories in Backlog Refinement Meetings separate form Planning Meetings. In these meetings, larger sets of user stories can be estimated than in a Planning Meeting because only just enough detail need to be discussed to estimate user stories relative to each other. At least the product owner and team representatives of all the disciplines that work on the Product Backlog must be present. Especially if multiple teams work from one product backlog, it is not always feasible to include everyone in every session.
Backlog Refinement Meetings are also a good place to discuss how to split up larger user stories into smaller ones and identify user stories that need further clarification. This is the reason why I prefer the term Backlog Refinement Meeting instead of Estimation Meeting. In Sprint Planning Meetings, only estimated user stories are discussed that have been identified to be READY for the team to start to work on.
The best and most widely used technique to estimate Product Backlog items is to estimate in story points using planning poker. If many items need to be estimated in a short time you can also consider an alternative approach that I have lined out in an earlier blog: let the team order them all at once on a horizontal scale and then assign story points.
Now that we have discussed the Backlog Refinement Meeting, note that there are strong analogies between Iteration planning and Release planning, detailed out in the following table:

With this blog I hope that I have helped some ScrumMasters a little further in applying Scrum to do projects successfully. I will now start to think about by next Tip for ScrumMasters …