Tips for ScrumMasters: Estimate user stories outside Sprint Planning Meetings
Posted by Marco Mulder mid-afternoon: November 11th, 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 a series of blogs, I want to share some best practices that I have found useful for ScumMasters. In this first 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 ...
Archives
Training
- Workshop Agile Management
Custom made, in-company - Scrum for Team Members
Custom made, in-company
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)
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.
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.
Marko,
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:
http://www-01.ibm.com/software/awdtools/rup/
Uladzimir.
@Iwein:
Even if you can do without a roadmap based on velocity and estimated backlog items, it is still a good idea to prepare user stories so that they are READY before you start a sprint. It is wise to allocate some time for this. With user stories that are not READY, the team will often loose much more time. I have seen this happen in several projects: while working on user stories in a Sprint, teams have to wait for answers for clarification from the Product Owner who waits for answers from the stakeholders that he represents. Preparing user stories to a state where enough is clear about them to prevent this can increase the velocity of the team a lot.
@Abderrazak, Uladzimir:
Jeff Sutherland, inventor of Scrum, defines Scrum as follows:
Scrum as an open development framework with a simple set of rules. The rules are constraints on behavior that cause a complex adaptive system to self- organize into an intelligent state.
My point about Scrum being a framework is this: there are many things that Scrum does not prescribe. This is on purpose. It leaves a lot of room for teams to self organize themselves in many different contexts. It also leaves plenty of room for sharing best practices, which will often be less generically applicable than Scrum itself.
Hi,
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,
Andreas
Hi Andreas,
Thanks for your comment. I completely agree with you that it is not necessary for the Product Owner to always have whole teams present when discussing how to break up user stories into smaller ones. Breaking up user stories is part of getting them READY. To do this, the Product Owner needs to involve team members, but also business stakeholders, operations etc. Backlog Refinement sessions are therefore not the only place where user stories are split, it just often happens at such meetings as well.
Especially in projects with multiple teams working from one Product Backlog, it is even not feasible to include all members of all teams in Backlog Refinement sessions to estimate user stories. In my opinion, the only time for which it is not debatable whether the whole team needs to be present to discuss user stories is the Sprint Planning Meeting. This is the only time when a team commits to a set of user stories. Estimates that are given in Backlog Refinement meetings should be interpreted as commitments. Using relative estimates in story points helps to avoid this trap.