8 Agile Estimation Techniques To Try With Your Team - Parabol

04/01/2023, 21:49 8 Agile Estimation Techniques to Try With your Team | Parabol
🌏 Join our fully-remote, global team! Build an open-source product that makes every meeting worthwhile →
8 Agile Estimation Techniques

to Try With your Team
The ability to plan ahead is what sets humans apart from all other species.
https://www.parabol.co/blog/agile-estimation-techniques/ 1/23
But it turns out we’re not all that good at it.
Cognitive bias, group-think, optimism, pessimism and even our evolutionary development, all lead
us to make errors.
And yet we still make estimates.
Because estimates helps us to sketch a rough idea of what the future might look like. They help us
budget resources. And they help us meet our deadlines.
Even if our estimates turn out wrong, teams still find value in the process of getting on the same
page about their work.
That’s why we’ve laid out a menu of 8 agile estimation techniques to try with your team.
1. T-Shirt Sizing
2. Sprint Poker
3. Three Point Method
4. Affinity Estimation
5. Relative Mass Evaluation ⚖️

6. Dot Voting
7. Maximum Allowable Size ⛔

8. Big, Uncertain, Small
These techniques can help spice up your backlog refinement sessions, leading to some unexpected
and productive conversations.
Humans may be flawed estimators, but with the right techniques, we can certainly improve.
So without further ado, let’s get into it.
1. T-Shirt Sizing
An agile estimation technique for making rough estimates
Let’s start with something simple and fun.
T-Shirt Sizing is one of the most well-known estimation techniques. It is used to get a high-level
estimate of the relative size of projects.
Teams assign rough estimates using a scale of t-shirt sizes like XS, S, M, L, XL. You can even add
an XXL if you want to root out those pesky epics masquerading as stories.
Try this method in Parabol
To get started with T-Shirt Sizing, the Product Owner should read out each story and ask the team
to select the relative size of a user story in terms of effort. You can do this process blind to prevent
bias, or simply ask your team members to write their estimates in Slack or Zoom.
Like the Sailboat or Mountain Climber retrospective, T-Shirt Sizing relies on a metaphor.
So it provides a great opportunity to get creative with your team.
Find t-shirts a bit boring? Use a different ordering method that resonates for your team and your
unique culture.
If your team are all dog owners, use a dog scale:
“That story’s clearly a Chihuahua, but the other one is a Great Dane.”
Or maybe you’re into exotic fruits, like us? Try out this scale:
Strawberry 🍓, Kiwi 🥝, Orange 🍊, Coconut 🥥, Watermelon 🍉
If a story is too weird or difficult to estimate, call it a Durian – because that’s one heck of a mind-
boggling fruit.
When to use it: T-Shirt Sizing is great when you need to arrive at only a rough
estimate of size. Use it to filter out stories that are too big and should be broken
down further. Or use it when you are picking from among projects that are
already large. Follow up on T-Shirt Sizing with a more refined estimation scale
such as actual hours.
Recommended for: New teams; Large Backlogs; Early-stage estimation
2. Sprint Poker
A process for precise, team-focused agile estimation
Planning Poker or Sprint Poker is more of a process than a technique, but it’s so useful that we had
to include it. Sprint Poker is a gamified estimation technique that helps you reduce the cognitive
bias of anchoring and arrive at more detailed estimations.
Try this method in Parabol
So it’s a win-win!
How does Sprint Poker work? It’s easy and fun.
The product owner distributes a set of cards to each member of the team.
And just like in real poker, you’ll want to keep your cards close to your chest.
The cards have a scale of numbers on them. You may also have a question and a pass card. After
reading out a user story, the product owner asks the team to reveal their chosen estimate by
showing one of their cards.
The value of the card you select should correspond to the amount of effort that story will take. The
estimation scale on your cards may be actual (in terms of hours) or abstract as story points (on a
fictional weighted scale).
Here are a few popular estimation scales you can try out:
• Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89

• Modified Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
• Actual hours: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10+
• Powers of two: 1, 2, 4, 8, 16, 32, 64
• Playing cards: Ace, 2, 3, 8, King (where a king signifies an item too complex to estimate)
When everyone reveals their cards, you may find that everyone has chosen a different one. This
gives you an opportunity to open up and have a conversation about why estimates are so different.
Perhaps Joe knows something about the product infrastructure that you didn’t know about. Maybe
Anna didn’t factor in the additional QA testing needed to ship that feature.
Following your discussions, you’ll negotiate a more accurate estimate taking in everyone’s
perspective. And in the process, you’ll all build shared context that will inform future estimates.
When to use it: Sprint Poker is great for teams that have a discrete number of
stories that they want to discuss in detail. It’s suitable for any team, but works
especially well with high-performing teams with lots of shared context. The
technique prevents anchoring and gives you a defined number that you can
convert into hours, should you wish to.
Recommended for: Established teams; Prioritised backlogs; Late-stage estimation
3. Three-Point Method
A technique to consider the best- and worst-case scenarios
Confession alert. I’m a bit biased because this might be one of my favourite estimation techniques.
In case you’re interested in why, it’s because Three Point Estimation is a technique that factors in
the best case scenario, the worst case scenario, and the most likely scenario to triangulate an
estimate.
The average of three estimates, gives you your final estimate.
You can use an hourly scale or an abstract one to arrive at your guesses. But whichever route you
take, you’ll end up with a more nuanced estimate having taken into account multiple scenarios.
This technique forces a conversation early on about likely blockers because you’re explicitly
considering a negative outcome. And these early conversations can help you pre-empt these
blockers during the refinement process itself, making success more likely.
So, how does it work? First ask your team to put on their optimist hat and their pessimist hat.
Then pose the following questions:
• How long/how much effort will this story take if everything goes well? (Optimist value)
• How long/how much effort will it take if you run into blockers. (Pessimist value)
• And based on that information, what’s most likely? (Most likely value)
Once you’ve got three figures, it’s time to whip out your calculator to average the scores.
There are two options for how to calculate your average:
Triangular averages weight each value equally

Estimate = (O+P+M)/3
Beta distributions weight the most likely value

Estimate = (O+P+4M)/6
The Beta method will give you a more accurate method by matching the regular distribution curve
more closely.
When to use it: The Three Point estimation method is a good option for teams
that want to have an upfront discussion about what a best case and worst case
scenario looks like. This can act as a mini pre-mortem to the sprint and raise
awareness of challenges in advance. It’s also great for teams who want to arrive
at a realistic estimate of how long a task will take rather than something more
aspirational. It’s a good estimation technique for new and old teams alike.
Recommended for: New teams; Prioritized backlogs; Late-stage estimation
4. Affinity Estimation
An agile estimation technique that reduces cognitive load
Have you ever been in a store looking at a series of products and not known which to pick?
Sometimes it’s easier to know what you don’t want than to pick a clear winner.
Well, if that confusion resonates with you, affinity estimation might be the technique you need.
Instead of asking the team to set an estimate outright, affinity estimation is all about comparisons.
Affinity estimation lowers the cognitive load and helps teams process more user stories, faster.
Here’s looking at all you folks with a humongous backlog!
How does it work? It’s quite simple really. The product owner takes the first item and asks the team
to set an estimate for it, using any scale as a base.. Let’s say, for example, that the team have
agreed a story is an 8 on their scale.
When you read out the next story, the task is simply to compare it. Is that story larger or smaller
than the 8 we’ve already identified?
If your team-members have differing views on a particular story, have an open discussion about
it.
Ask team members to state why they believe an item is smaller or larger. Here’s what that
conversation might look like:
🧑‍💻
‍ Joshua: When we set up the sharing function last time it took a long time,
but we can use our learnings this time to do it more quickly – that’s why I think
it’s lower
👩‍💻
‍ Charlotte: That’s true, we have some inherited knowledge. But for this
sharing function, we need to build additional functionalities that we haven’t
built before. We ran into some problems last time and we might again,
especially with testing. That’s why I think it should be higher.
Once this exercise has been carried out for all your stories, you can decide on the next steps.
Perhaps all the items smaller are good to go already and you want to focus on estimating the larger
ones in more detail?
When to use it? Affinity estimation is a great way of blitzing through a large and
un-estimated backlog. Perhaps you’re a new team that’s inherited a backlog?
Maybe you’re starting a new project altogether? Affinity estimation helps you
parse out items and arrive at a vague estimate. When the backlog is clearly
prioritised, you can use a more precise estimation technique for those items.
Recommended for: Large backlogs; Early-stage estimation
5. Relative Mass Evaluation ⚖️

A balance of precision and speed in agile estimation
This estimation technique sometimes goes by another name: the Ordering Protocol.Let’s be
honest, both names are kind of jargony. But Relative Mass Evaluation (RME) at least tells you what
it does from the off. You measure the relative mass of items in relation to each other.
Unlike Affinity Estimation where you are comparing one story with another, RMA takes into account
all the stories so far and encourages your team to generate estimates based on a holistic view of
stories under consideration.
One of the best ways to do RMA is to set out a scale on the table. This can be a numbered scale to
give people anchors to hang onto. And as a product owner, you’re going to read out user stories and
ask the team to place them somewhere on that scale.
This method of estimation is highly collaborative, as team members can move items around on the
scale. And it doesn’t require team members to set a defined number of hours – unless of course
you want to!
When to use it: Relative mass evaluation is another good technique for when
you have a lot of items to evaluate in a limited amount of time. Simply placing
them somewhere on a scale and agreeing the precise definition after can be a
quicker way of getting a feel for the relative effort of each user story. However,
you may run into challenges when converting your estimates into an integer
value.
Recommended for: Large backlogs; Early-stage estimation
6. Dot voting
An agile technique that builds on a familiar practice
Remember that thing you do sometimes in your retrospectives where you vote using dots? Well,
turns out you can also use it to estimate user stories.
Dot voting is a deceptively simple, but rather effective way of expressing how much effort you
expect something will take. Set up your user stories visually, either on a whiteboard, or in a digital
tool, and assign everyone a colour.
Next, set the scale you want to use as a group. In this case, I’d recommend a simple 1-5 scale.
Otherwise counting all those dots can send you… well, dotty.
Pro tip: As a facilitator, you want to make sure everyone understands the scale.
Because if Jennifer thinks the scale is absolute (in hours) and Geoff thinks its
relative (abstract reflection of effort), you’re not going to get useful results.
Now, you’re going to ask everyone to add the number of dots to a story that best represents the
effort required to complete it. Once everyone has voted, discuss the results and iron out any
discrepancies.
One thing you might struggle with in dot voting is preventing the cognitive bias of anchoring.
When everyone can see dots materialising on sticky notes, it’s easy for groupthink to take hold.
Finding a way to hide and then reveal votes is something that will vastly improve your estimates.
When to use it: Dot voting is a very simple way of estimating, and you can get
through a good number of stories in a short amount of time. It’s best when you
have a physical or virtual whiteboard, which allows you to visually spot
patterns. The risk of anchoring makes this estimation technique a better option
for established teams with more shared context.
Recommended for: Established teams; Large backlogs
7. Maximum allowable size (MAS) ⛔

A way to quickly sift through stories and see what needs
breaking-down
The Maximum Allowable Size estimation technique is a bit like baking. One of the key ingredients in
any baked product is flour. And there’s one thing you need to do with flour before adding it to the
mixing bowl. Sieve it. Nobody wants to eat a cake with big lumps of baked flour in it!
That’s exactly what you’re going to do with the MAS technique: sieve out the big pieces.
This estimation technique helps your team identify epics early on, and break them down into
multiple, smaller user stories. It’s a great technique for sifting through a large backlog full of big
ideas to isolate what needs to be broken down, and what’s ready for action.
Here’s how it works.
First, you set your estimation scale. In this case, it might be worth using a scale according to the
number of hours something will take, so you have a concrete idea of the maximum amount of time
you want your team to spend on a given piece of work. This will make your filtration more
actionable.
As a general rule, user stories probably shouldn’t take more than 16 hours of work, otherwise
they can become unwieldy. So you might want to take 16 hours as your maximum allowable size. If
you don’t need the same level of precision, use the good old t-shirt sizes to guide you.
Now the task is to go through all the stories in your backlog and filter out the ones the team think
are higher than 16 hours by voting on them.
You can then take those items and discuss how to break them down so they fit below the maximum
allowable size.
It’s as simple as that.
When to use it: Use the Maximum Allowable Size technique if you suspect there
are epics hiding as stories in your product backlog. Additionally, if you notice
that your team is struggling to finish items during the sprint, a run through of
the backlog using MAS might give you peace of mind that items are indeed the
right size to be taken into the Sprint Backlog. You might also try this technique
when you have large floundering items at the bottom of the backlog that you
want to start prioritising and that you want to break down into manageable
pieces.
Recommended for: Established teams; Large backlogs, Early-stage estimation
8. Big, Uncertain, Small
An agile estimation technique that tackles uncertainty head-

on
You’re probably familiar with the initialism KISS. It stands for Keep It Simple, Stupid. Well, this
estimation couldn’t get much simpler. Want to do a first pass of multiple items in your backlog? This
could be a good contender.
Big, Small, Uncertain is an agile estimation technique that quickly focuses on the things you need
to discuss. Small items get marked appropriately and they don’t need to be discussed. Big items
can be earmarked for future estimation sessions, using a more refined scale. That leaves uncertain
items as the prime focus of your conversation.
Big, Uncertain, Small, gives the team permission to simply say “I don’t know if it’s big or small”.
Sometimes that means the item falls in the middle. Other times, it can indicate areas where the
team has less context to base their decision on.
You can then proceed to have an open discussion about the user story:
• What are the big unknowns that prevent us from reaching a decision?
• What data or information do we need to make those things known?
When to use it: This estimation method is worth trying out when you have a
large amount of stories to estimate but want to focus on areas where the team
lacks context. This estimation technique is simple and the scale is limited,
which makes it a good candidate for newly-formed teams that have less prior
data to make decisions based on.
Recommended for: New teams; Early-stage estimation
Which Agile Estimation Technique Should Your

Team Use?
Sign In Get Parabol
With so many options, it might be daunting trying to figure out which agile estimation technique is
the right one for your team and backlog.
But as with everything in agile: which estimation technique you choose depends on what results
you want to get.
The best way to find a technique that works for you, is to simply try it out. Use our handy table to
decide where to start.
Not every technique will deliver the results you want, but going into the process with an
experimental mindset will help you to learn what you do need from your estimation sessions.
In Retrospectives, we hear that Scrum Masters often switch up the meeting templates they use.
The goal is not only to keep retrospectives fun for the team, but to use different prompts to solicit
different kinds of answers.
It’s the same with estimation.
The end-goal of estimating stories is identical no matter which technique you use. But the
technique you employ can prompt different discussions in your team.
For example:
• The Three Point Method encourages team members to discuss best and worst case scenarios to
identify problems early on. Try the Three Point Method you find your team is generally over-
optimistic, or if you are running into a lot of unexpected blockers.
• Sprint Poker or Planning Poker gives teams an opportunity to estimate on a more refined scale
that encourages more nuanced conversations. Try it if you find a need for more precision with
your estimation.
• Big, Uncertain, Small, prompts conversations about where the team lack context to make
decisions. Try it to kick-start discussions around estimation, especially for a team that hasn’t
done it before, or a backlog that’s rough around the edges.
So adjust your estimation technique according to the types of conversations you want to have.
All that leaves is for us to wish you best of luck with your estimations!
Gareth Davies
Gareth is a growth marketer at Parabol. He has spent his career helping

people and organizations around the world communicate better. He
likes learning languages, cycling, and journalling. He originally hails
from Wales, but lives and works in Munich, Germany.
Try Parabol Sprint Poker For Better Story

Point Estimates
Estimate remotely with an interactive deck of cards, built-in anonymity, and two-way
integrations with Jira, GitHub, Gitlab, and AzureDevOps. Sprint Poker makes
estimation meetings fun, gets people talking, and helps teams craft better estimates.
Get Parabol See how it works
Backlog Refinement
Sprint Velocity: How to Measure and Use Velocity Story Points: The Simple Explanation You've Been Fibonacci Agile Estimation:
in Agile Looking For Does it Work?
Backlog Refinement · 11 min read Backlog Refinement · 8 min read Backlog Refinement · 5 min read
Features Resources Purpose Support

Agile Meeting Templates Icebreakers Guide Press Retrospective Meetings 101
Integrations Retrospective Guide Media Kit Sprint Poker Meetings 101
Pricing Planning Poker Guide Team Check-in Meetings 101
Enterprise Sprint Planning Guide Diversity Statement Contact

Daily Scrum Guide Friday Ship
Blog Join Our Team
Privacy Terms of Service © Parabol, 2023

8 Agile Estimation Techniques To Try With Your Team - Parabol

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8 Agile Estimation Techniques To Try With Your Team - Parabol

Uploaded by

Copyright:

Available Formats

04/01/2023, 21:49 8 Agile Estimation Techniques to Try With your Team | Parabol

8 Agile Estimation Techniques

But it turns out we’re not all that good at it.

And yet we still make estimates.

3. Three Point Method

5. Relative Mass Evaluation ⚖️

7. Maximum Allowable Size ⛔

So without further ado, let’s get into it.

An agile estimation technique for making rough estimates

Let’s start with something simple and fun.

Try this method in Parabol

So it provides a great opportunity to get creative with your team.

If your team are all dog owners, use a dog scale:

Strawberry 🍓, Kiwi 🥝, Orange 🍊, Coconut 🥥, Watermelon 🍉

Recommended for: New teams; Large Backlogs; Early-stage estimation

A process for precise, team-focused agile estimation

Try this method in Parabol

How does Sprint Poker work? It’s easy and fun.

• Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89

Recommended for: Established teams; Prioritised backlogs; Late-stage estimation

A technique to consider the best- and worst-case scenarios

The average of three estimates, gives you your final estimate.

Then pose the following questions:

There are two options for how to calculate your average:

Triangular averages weight each value equally

Beta distributions weight the most likely value

An agile estimation technique that reduces cognitive load

Here’s looking at all you folks with a humongous backlog!

5. Relative Mass Evaluation ⚖️

Recommended for: Large backlogs; Early-stage estimation

An agile technique that builds on a familiar practice

Recommended for: Established teams; Large backlogs

7. Maximum allowable size (MAS) ⛔

Here’s how it works.

It’s as simple as that.

Recommended for: Established teams; Large backlogs, Early-stage estimation

8. Big, Uncertain, Small

An agile estimation technique that tackles uncertainty head-

Recommended for: New teams; Early-stage estimation

Which Agile Estimation Technique Should Your

It’s the same with estimation.

Gareth is a growth marketer at Parabol. He has spent his career helping

Try Parabol Sprint Poker For Better Story

Get Parabol See how it works

Features Resources Purpose Support

Integrations Retrospective Guide Media Kit Sprint Poker Meetings 101

Enterprise Sprint Planning Guide Diversity Statement Contact

Blog Join Our Team

Privacy Terms of Service © Parabol, 2023

You might also like