Relative estimation, using story points, has proven itself superior to traditional time-guessing approaches. Common approaches to creating story point estimates, notably planning poker, aren’t great at getting the whole team involved in the conversation. Usually, only the outliers participate. This article describes a better approach, which we have been using with our clients for years.
Anchor The Scale
Find or create a ridiculously easy story (product backlog item). Perhaps something like: “Fix the misspelled word in the help text.” You want a story so easy that the developers are grumbling that it would be faster to just do it than to talk about it. Perfect! Declare that to be a one-point story. This defines one story point of work to be about as much work as it takes to do that super-simple item.
How To Start
Lay out the Fibonacci numbers: 1, 2, 3, 5, etc. on a table or in a shared spreadsheet. When doing this online I usually use Google Sheets, as they allow the whole team to interact with a spreadsheet in real time. Place that reference story in the column (or row) labeled ‘1.’ If your team already has stories that you have estimated together in the past, you could place those on the board at this time as well, placing them in columns (or rows) under the number corresponding to their estimate. Thus, all of the one-point stories will be under the number one. All of the two-point stories will be in a column under the number two, and so on. All of the unestimated stories are in a stack on the side of the table, or in their own column in your spreadsheet.
Pick an order for team members to act, just like a turn based game. When it is a player’s turn, they have two options:
- Estimate A New Story – They can give a new story an estimate by placing it in a column.
- Change An Estimate – They can move a story to a different column.
Conversation is strongly encouraged as this estimation game plays out. However, when it is a player’s turn, they are free to make the move they think is best even if others disagree. Over time, disagreements will lead to deeper and deeper discussions about the contested stories. The whole team will be involved in these conversations, leading to a better shared understanding of the problem and the plan for solution. Ultimately, each story will find its place.
It’s Not About Numbers
One of the things I like about this approach is that people quickly stop thinking about numbers. They tend not to say, “This feels like an eight.” They are more likely to say, “This is a lot like the other items in this column, so I’ll put it here.” We do a lot better when we do this sort of qualitative thinking, identifying things that are similar in the type and amount of work, as opposed to jumping straight to quantification.
Nothing Is Too Big To Estimate
When assigning story points to a story, the team will consider: effort, complexity, and risk. Effort is how much work we believe is required. Complexity is how tricky or complicated the work is likely to be. Risk is related to how much is unknown. If we think we only understand a small portion of the problem or solution, then risk is high and so the estimate should be high.
When a new request comes in, the team can create an estimate after only a few minutes of conversation. Of course, the estimate is likely to be high, since the amount of unknown is probably high. That’s okay; it’s a starting point. Sometimes all that is needed right now is a sense of whether this item is a ‘quick win’ or not. A high initial estimate allows the product owner to decide if they care enough to pursue the item or not.
Let’s say an item was given a large estimate, perhaps 233 or 377 points, because there is a lot that is unknown about the story. A good next step is to create some refinement tasks (sometimes called spikes) to do further investigation. In a future refinement session, the results of the investigation can be shared and the estimate further refined.
Watch A Team Do It
Keep Doing It
I encourage teams to do this exercise every week at their backlog refinement meeting. Over time, the team’s understanding of the items in their backlog will increase dramatically. A nice side effect will be that the estimates will continually improve. Our clients have been using this approach for well over a decade. Try it, and let us know how you like it.
Credit Where Credit Is Due
- How to play the Team Estimation Game
- Don’t Change Estimates During Sprint Planning
- Daddy, Where Do Product Backlog Items Come From?
- Story Point Accounting Across Sprints
- 12 common mistakes made when using Story Points
- A spreadsheet you can use for Easy Estimation
- Video: Easy Estimation With Story Points @ Scrum Professionals Meetup