Estimation is one of those topics in Agile where we have managed to make something that should be relatively simple incredibly complicated. We talk about estimation, sizing, story points, Planning Poker, velocity and forecasting, and very often we mix all of these things together as if they are the same thing. They are not.
A lot of the bad practices we see around Agile estimation come from exactly this misunderstanding. We have introduced story points, Fibonacci numbers and Planning Poker, but in many organisations, we have never actually changed the thinking underneath them. We are still trying to answer the same old question: How long will this take?
Of course, organisations need predictability. Stakeholders need dates, budgets need to be approved and people need to make decisions. The problem is that we often ask teams for the most certainty at exactly the point where they know the least about the work. We then take that estimate, put it into a project plan and slowly turn what started as an assumption into a commitment.
Maybe the problem isn’t that teams are bad at estimating. Maybe we are asking the wrong question.
Why Is Time Estimation So Difficult in Agile?
Think about something incredibly simple: an apple. Most of us have seen thousands of apples, yet if I show you one and ask you exactly how much it weighs, you probably cannot tell me. You can guess, somebody else can guess, and we can even take an average of everyone’s guesses, but that doesn’t suddenly make us right.
Now think about what we ask teams to estimate: complex work, changing requirements, dependencies, new technology and problems they may never have solved before. Yet somehow, we expect them to tell us exactly how many hours it will take. This is where I think our language matters. Instead of asking, “How long will this take?”, relative sizing asks, “Is this bigger or smaller than something we already understand?”
Put a pineapple next to the apple and suddenly the conversation becomes much easier. I still cannot tell you exactly what either weighs, but I can confidently tell you which one is bigger. That is the power of relative sizing. We are not trying to make uncertainty disappear by putting a precise-looking number on it. We are finding a better way to work with it.
Should Story Points Be Converted Into Hours?
No. And this is probably one of the Agile anti-patterns that frustrates me the most.
Story points are not hours or days, and the moment we say that one story point equals a certain number of hours, I would question why we are using story points at all. We have simply reinvented time estimation using different numbers.
I see this happen all the time. Teams stop estimating in hours and start using Planning Poker. Someone says an item is a 3, somebody else says it is an 8, and suddenly we spend 30 minutes negotiating whether it should be a 3, 5 or 8. Eventually somebody asks, “Okay, but approximately how many hours is an 8?” And we are right back where we started.
Giving everybody Fibonacci cards does not mean you are doing relative sizing. If people are still individually estimating time and translating that thinking into story points, the underlying behaviour has not changed. Story points are useful because they are relative. A 5 does not mean five hours, five days or five of anything. It means that compared with other work this team understands, this item belongs roughly in the same size category.
How Does Relative Sizing Work?
Relative sizing is actually quite simple, but it requires us to change the question we ask. Instead of looking at a Product Backlog Item and asking, “How big is this?”, we compare it with something the team already understands and ask, “Is this bigger or smaller?”
To get started, the team needs a baseline. I normally recommend finding a Product Backlog Item that everyone understands reasonably well and giving it a 3. There is nothing magical about 3, and you could start somewhere else, but I like it because it gives us room to move both down and up. What I would not recommend is trying to find your smallest possible item and calling that your starting point. A Product Backlog is emergent, so how could we possibly know at the beginning that we have already found the smallest thing we will ever do?
Once we have our baseline, we take another item and compare it. Is it bigger or smaller than our 3? If it is bigger, is it closer to a 5 or an 8? We continue in this way, always comparing rather than trying to determine an absolute size. Over time, the team builds its own reference points based on work they have actually seen and understood.
This is also where uncertainty becomes important. If the team looks at an item and there are significant unknowns, that should be reflected in the size. We do not need to sit in a meeting for an hour trying to create certainty that simply does not exist yet. Give it a larger size, learn more about it and split it as our understanding improves. A large item might eventually become several 3s, 5s and 8s, spreading the uncertainty across smaller pieces of work.
And don’t get stuck trying to achieve false precision. If half the team believes something is a 3 and the other half believes it is a 5, have the conversation to make sure there isn’t something important being misunderstood, but if there isn’t, I would rather take the 5 and move on. The value is in the shared understanding created through the conversation, not in spending another 30 minutes trying to prove that one number is more correct than another.
That is what makes relative sizing useful. The numbers themselves are not the goal. They give the team a simple language for comparing work, making uncertainty visible and building the consistency we later need to forecast based on what the team actually delivers.
What Should Velocity Actually Be Used For?
Velocity has become one of the most misused concepts in Agile. It should not be a performance target, and it should definitely not be used to compare teams. Forty story points from one team are not automatically “better” than twenty-five from another because their story points are based on completely different baselines.
Velocity is useful for one thing: helping a team forecast based on what it has actually demonstrated it can deliver.
When a new team starts, we don’t have that data. Run a Sprint and we get our first data point. Run another and we get another. I normally like four or five Sprints before putting too much confidence into the pattern.
Perhaps the team completes 15 points, then 21, 19 and 23. No Sprint will be exactly the same because teams consist of humans. People get sick, public holidays happen, production issues appear and teams learn. That variation is normal. The mistake is taking an average velocity of, for example, 20 and turning it into a target of 20 points every Sprint. The average is there to help us understand a pattern, not to become another KPI.
From Agile Estimation to Evidence-Based Forecasting
Relative sizing and velocity become powerful together. If we understand approximately how much work remains and have evidence of how much the team typically completes, we can start forecasting where delivery is likely to land.
I like using a burn-up chart for this because it makes reality visible. If new scope is added, we can see what happens to the forecast. If scope is removed, we see the impact. If the team’s delivery pattern changes, our forecast changes with it.
That creates a very different stakeholder conversation. Instead of defending a date created months ago when everybody knew significantly less, we can show what the data is telling us now and make decisions based on that.
This is where I think organisations need to challenge themselves. We talk endlessly about becoming data-driven, yet some of our most important delivery decisions are still based on estimates made before the work even started. Moving away from traditional time estimation does not mean abandoning predictability. It means becoming more serious about how we create it.
Relative sizing gives us a better way of working with uncertainty. Story points give teams a relative scale without pretending the numbers represent time. Velocity gives us historical evidence, and forecasting allows us to use that evidence to understand where we are likely to land.
We don’t need organisations to become better at extracting estimates from teams. We need them to become better at using evidence to predict what is likely to happen next.
Want to go deeper?
This article is based on our Meetup session on The Power of Relative Sizing. Watch the full recording to see the practical examples and a deeper discussion on relative sizing, story points, velocity and forecasting.
