8 Agile Estimation Techniques to Try With your Team | Parabol Skip to main content

8 Agile Estimation Techniques to Try With your Team

Five fingers estimation

The ability to plan ahead is what sets humans apart from all other species.

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.

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

T-Shirt size estimation

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.

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.

T-Shirt Sizing is Boring - Use Dogs or Fruit Instead-1

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

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

Fibonacci Scale - 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.

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

Three Point Method Agile Estimation Technique

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:

Refinement before and after

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

Affinity Grouping Estimation Technique

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

Relative Mass Evaluation Agile Estimation Technique

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

Dot Voting Agile Estimation Technique

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

Maximum Allowable Size Agile Estimation Technique

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

Big Uncertain Small Agile Estimation Technique

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?

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. 

Which Agile Estimation Technique is Right For YouNot 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!