Tips for ScrumMasters: Estimate user stories outside Sprint Planning Meetings

11 Nov, 2009

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:

Iteration Planning Release Planning
When estimated Sprint Planning Meeting Backlog Refinement Meeting
Used to Plan what can be done in a Sprint Plan what can be done before a release date
Planned item Task User Story
Unit of measure Hours Story Points
How estimated Design discussion Planning Poker
Progress is tracked on Sprint Burndown chart Release Burndown chart

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 …

Newest Most Voted
Inline Feedbacks
View all comments
12 years ago

Thank you for the post,
Just something to say, I think that SCRUM is not a “Framework” as mentioned earlier within the post, because that a framework defines a boundary(ies), I until now don’t heard about boundary(ies) for SCRUM.

Iwein Fuld
12 years ago

I do appreciate yet another attempt at structuring the life cycle of a user story better. Having a good roadmap is what is lacking in many environments I’ve worked in. On the other hand, the single biggest challenge for any project team is to keep focus. In my current team we’re losing almost 10% of our time in meetings, I’m very reluctant to add another one to the list.

Uladzimir Liashkevich
12 years ago

Methodology-framework: I always thought it was vice versa – RUP is a framework and SCRUM is a methodology. Though I’m not absolutely sure that SCRUM is *not* a framework.
Concerning RUP:

Andreas Ebbert-Karroum
12 years ago

thanks for emphasizing that there is a need for a planning meeting prior to the sprint planning, needed at irregular intervals, depending on how many new stories are discovered, and how frequently they have to be broken down into smaller ones.
Regarding the “Backlog Refinement Meeting”, do you really think it is necessary, to have the whole team discuss how to break up stories into smaller pieces? In my opinion this is what the product owner is responsible for. It’s difficult, agreed, and he might need some help, but does it have to be the whole team? When the resulting stories are estimated, the whole teams needs to be present and understand the stories, that’s out of question.
Kind Regards,

Explore related posts