Relative Estimation
"It is better to be roughly right than precisely wrong." - John Maynard Keynes, British economist
Estimation is one of the most controversial topics in product development. Why? Because teams fear being held accountable for numbers that are, by nature, uncertain. Some add buffers to "protect" themselves; others argue that estimating complex work is pointless.
The goal of relative estimation is simple: better conversations about the problem. The Product Owner’s job is to maximise ROI by weighing business value against the size and complexity of the work. The question is: "How much value can I get for this investment?" Relative estimation answers both parts of that equation – value and investment.
Planning Poker is the facilitation technique that makes this happen. It ensures every team member’s opinion counts while keeping the process effective. Teams use physical cards or smartphone apps with a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? – and ☕.
Planning Poker can be used for teams and their Product Owner to get an understanding of the investment, and it can be used by the Product Owner with stakeholders, to align on the expected business value. For both groups the process is the same.
Why relative estimation makes sense
Team members often hesitate to estimate because their numbers get treated as commitments – no matter the assumptions or surprises that arise later. To "protect" themselves, they add buffers or multiply estimates by a factor (sometimes π, to make it look scientific). But piling up buffers reduces transparency and renders estimates useless.
Getting precise estimates takes time, but the extra effort rarely pays off. Estimates will never be 100% accurate, so spending less time estimating and more time delivering often yields better results. Relative estimation acknowledges this: it’s about size and complexity, not hours. We call this story points.
With relative estimation you do not need to be precise, you just need to be consistent in how bad your estimates are. At the same time relative estimation helps team members share their understandings of the job to do and agree on how much it is.
Why is that?
Here’s the thing: Peter, Paul, and Mary aren’t equally skilled at getting certain jobs done. Some tasks Peter can do faster than Paul – because he’s more experienced in that area. Other tasks, Paul outpaces Mary – and for others, Mary is the fastest. At the same time, Mary’s motivation and energy vary – some days she’s on fire, other days she’s running on fumes. Maybe she didn’t sleep well last night. On the days she’s energised, she gets a lot done; on the days she’s not, work barely flows. Humans aren’t robots. Our work is non-linear – interactions and output vary.
To balance this, we use story points. With story points, Peter, Paul, and Mary can agree that one task is a 5, another is a 13, and a third is an 8 – even if Peter is best at the first, Mary at the second, and Paul at the third. Is it exact science? No. But it evens out over time. It’s like swings and roundabouts – you win some, you lose some. Estimating complex work has never been – and never will be – an exact science.
To separate story points from time, the team must have a reference based on work they’ve already done – we normally call these user stories. They build this reference by comparing different work items to each other. Which is a 3, which is a 5, which is an 8? The team should maintain and refine their reference over time, while ensuring that the reference does not drift away.
A metaphor to understand story points
Consider a simple task: moving a pile of sand. The two people about to do this task can roughly agree on its volume (size) – and they can also agree on the complexity of moving it. To be honest, moving sand isn’t that complex – unless the sand is polluted, which makes the job more complex because it would require special handling and equipment.
The job of moving the sand has a certain combination of size and complexity – we could say this job is an 8. If it was polluted sand it might have been a 13 or a 20. Still, this doesn’t say anything about how long it will take. That depends on how the job is staffed. If one person moves the sand, it takes a certain amount of time; if two people do it, the time will differ (hopefully less). Maybe the two people aren’t equally skilled at moving sand. Maybe one has a sore back – then it will take longer if that person works alone. If the other person does it, it will go faster. Maybe the tools vary – one day they use buckets, another day wheelbarrows, and a third day an excavator. The time will vary, but the combination of size and complexity stays the same. It’s still a 13, no matter how many people do the job or which tools they use.
It’s not exact science, but over time it evens out – especially if you keep the reference and team stable.
How to play
At the start of Planning Poker, each team member is given a deck of cards. For each user story or theme to be estimated:
A moderator – typically the Product Owner, Scrum Master, or analyst – reads the description. The moderator does not vote.
Each team member privately chooses a card value based on their understanding of the story, when comparing it to the reference the team has made.
When everyone has chosen, all cards are shown simultaneously.
The team members with the highest and lowest values share their reasoning.
The Product Owner or stakeholder answers any questions from the team.
Each team member re-estimates by privately selecting a new card.
All cards are shown again so everyone can see the updated estimates.
The team members with the highest and lowest values discuss their reasoning once more.
After the discussion, each team member re-estimates a final time.
If there’s only a one-step difference between the remaining cards, the highest value is chosen.
If there’s still no consensus after the third round, the highest value is chosen.
Using Planning Poker for Business Value
The process is the same when it comes to business value. Here, the Product Owner and relevant stakeholders perform the relative estimation. Just as the team has a reference for story points, the Product Owner and stakeholders should have a reference for business value – preferably features that have already proven their value in the market.
During the estimation, their dialogue about business value should go beyond just money. They might discuss:
Will this feature open up new markets for us?
Can it help us upsell to existing customers?
Is this necessary to retain our market position?
Will it improve efficiency?
Is this required by legislation?
Will it strengthen our brand?
None of these aspects is inherently better than the others, but the discussion and alignment are what matter.
Using Relative Estimation for Forecasting
The purpose of estimating is to create predictable plans. That’s almost impossible when doing complex work – but that shouldn’t prevent us from at least trying. No matter how Agile we think we are, there’s still a need for synchronisation points like milestones or gates. Other departments – such as production, sales, or marketing – depend on knowing when we’ll finish developing a feature or product. Even though plans will change, we should still provide our best guess on what will happen and when we’ll be done.
Using relative estimation with story points, as well as measuring how many story points the team delivers in each sprint (their velocity), enables the Product Owner to make somewhat predictable plans. With the team’s willingness to estimate items in the Product Backlog – even if they’re only briefly described – it becomes a simple task for the Product Owner to draft which items are likely to fit into which sprints. This provides transparency on plans and progress, helping the Product Owner discuss priorities with stakeholders and make the best possible decisions.
The primary challenge in using velocity is that it varies over time. Several factors influence this:
Team members’ availability for teamwork
Interruptions in daily work
Variations in how well the team’s competencies match the current tasks
Team members’ focus and commitment to reaching the Sprint Goal
A good way to navigate this uncertainty is to use the 90% Confidence Interval of the velocity. While there are statistical formulas behind this, in practice, you use the second-highest and second-lowest velocity from the most recent eight sprints to define the interval for targeting future velocity.
Some teams add a buffer in the sprint for unplanned work. However, using relative estimation with story points and basing commitment and forecasting on measured velocity means this buffer is already accounted for. If a team pulls work according to their current velocity, the needed buffer is inherently included.
Final Thoughts
Using relative estimation provides a simple way to navigate the complexity of product development in a modern world. However, your ability to do so doesn’t come out of the blue – there’s a long chain of conditions that must be in place for this to work. These include:
A clear understanding and feeling of accountability for the team’s purpose and goals
Team stability and interrelationships
The team’s agreement on roles and responsibilities
The Product Owner’s mandate and discipline in Backlog Refinement
The Scrum Master’s ability to shield the team from unplanned work
As you can see, there’s structure and process in using relative estimation, but in the end it boils down to culture. Relative estimation only works if you accept the uncertainty in complex work and empower the team to make their own decisions on how to get the job done. If you constantly are changing the team composition then this will never work.