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 Agile Learning Labs has been using with our clients for over a decade.
How To Start
This approach assumes that your team already has some estimated items in your product backlog. If you don’t, no worries, just use The Team Estimation Game to create your initial estimates. The Team Estimation Game was invented by Steve Bockman, who we at Agile Learning Labs were fortunate to work with for several years.
So, you have some product backlog items (stories) with estimates and some new items without. Start by laying out the Fibonacci numbers 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. Next, take the stories that have estimates and put them in columns 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 sub-tasks) to do further investigation. In a future refinement session, the results of the investigation can be shared and the estimate further refined.
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.
- 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