Agile Estimation Techniques & Activities
After researching as well as carrying out several of these estimation techniques over my career I wanted to put these items into an area that would allow for a team to be able to choose the best technique or exercise that suited them and their needs.
My suggestion and professional recommendation would be that no matter what you try and use, you DO NOT try to convert an estimate into person days/person hours or work effort alone. This invites a scope for finger-pointing and holding people accountable in the wrong ways to estimates that are, after all, only estimates.
Instead, we should use a technique that allows for relative and obscure measurements of effort, risk, and complexity and measure them over time against an estimated backlog to predict the end date of a project.
Working out a project end date:
- Chosen Velocity Metric ÷ Estimated Backlog + 15% = Best Case (Everything goes exactly as expected and minimal surprises happen -as they always do)
- Chosen Velocity Metric ÷ Estimated Backlog + 30% = Good Case
- Chosen Velocity Metric ÷ Estimated Backlog + 60% = Bad Case
- Chosen Velocity Metric ÷ Estimated Backlog + 90% = Worst Case (There’s fires everywhere)
Below I’ve listed out possible techniques, starting with ones that are suitable for smaller teams and smaller items building up to techniques more suitable for bigger chunks and bigger teams.
Not all techniques are suitable for all times, I’d recommend using one that fits the project need at the time. The beginning of a project would require a technique like Buckets as you’ll most likely be figuring out the work involved. However, during refinement sessions, I’d suggest picking one that the team has chosen and likes and can get used to.
If you ever find an estimation session becoming stale, or people are less engaged, mix the technique up!
Planning Poker
Recommended for: Established teams; Prioritised backlogs; Late-stage estimation
Teams of: Small Teams
Items of: Small Items
Description:
Each set of cards contain 12 cards namely 0, 1, 2, 3, 5, 8, 13, 20, 40, ? and coffee mug etc. Every estimator (devs/qa) will be given a set of cards and the user story selected will be explained by the Product Owner. The team will ask questions about the task before they choose the card to estimate the time for completing the task.
Then every estimator will independently choose one card and the others will not know what one has chosen. Later every card will be flipped open to know their estimate. Act as one team, you may have a team with both devs and testers but we all need to think as one team. Meaning, when you go into estimation, estimate items as one. When you’re relative sizing, you don’t need to break down the points into development/QA responsibilities, you are one team, estimate as one team, don’t split the estimates out.
If everyone has chosen the same card, then the estimate is easy, but if not the estimators with the highest value and lowest value will be asked to explain the reasoning for these estimations and another full round of estimations with the entire team will start again. Until each team chooses the cards with the same value.
Good conversation comes out of the discussions and averaging or just agreeing to a number when not everyone has chosen cards that are the same, allows teams to just fold and hide without a proper discussion, so keep the rounds going until a consensus is decided!
Person Days
Recommended for: New teams; Prioritised backlogs; Late-stage estimation
Teams of: Small Teams
Items of: Small Items
Description:
This technique is best used when following the exact same structure as the Planning Poker technique but rather than using an obscure relative scale you’re using each number in the Fibonacci Sequence to attribute them as Person Days.
I had previously mentioned that I don’t favour this technique for various reasons, however, this is still a technique that can be used.
Affinity Mapping
Recommended for: Established teams; Large backlogs; Early-stage estimation
Teams of: Small Teams
Items of: Small Items
Description:
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.
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 has agreed a story is an 8 on their scale.
Items are then grouped by similarity. 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.
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.
Large/Uncertain/Small
Recommended for: New teams; Early-stage estimation
Teams of: Small Teams
Items of: Small / Medium / Large Items
Description:
For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: large, uncertain and small. The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.
Once all items are completed everyone quietly reviews the items on the scale. If a participant finds an item that they believe is out of place, they are welcome to bring it to the attention of the group. The group then discusses it until consensus is reached and it is placed in one of the buckets.
Dot Voting
Recommended for: Established teams; Large backlogs
Teams of: Small Teams
Items of: Small / Medium / Large Items
Description:
Each person gets a number of dots and uses them to vote on which projects are big and small. More dots mean more time and effort is required. Fewer dots indicate a fairly straightforward and quick item.
This technique isn’t good for gauging velocity within a team. However, it’s a really good way to estimate a large backlog and decide what items need to be broken down more.
Coupled with a bucket technique of T-Shirt Sizes this can quickly help identify sizes of items in an entire backlog very quickly giving the PO a sense of the size of items listed in a backlog.
Three-Point Method
Recommended for: New teams; Prioritized backlogs; Late-stage estimation
Teams of: Small / Medium Teams
Items of: Small / Medium / Large Items
Description:
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 better 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. These early conversations can help you pre-empt these blockers during the refinement process itself, making success more likely.
Ask the following questions during each refinement meeting.
- 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
You can choose two averaging techniques.
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.
Ordering Method
Recommended for: Large backlogs; Early-stage estimation
Teams of: Small Teams
Items of: Small / Medium / Large Items
Description:
An item is placed with a random ordering on a scale (low to high) with several steps in between e.g You could choose the Fibonacci scale here.
Then the team is asked, randomly one at a time. To move the item on the scale one up, one down, discuss or pass.
The process is done once everyone passes on their turn.
With limited time your PO can select the items and prioritise them.
Maximum Size or Less
Recommended for: Established teams; Large backlogs; Early-stage estimation
Teams of: Small / Medium Teams
Items of: Small / Medium / Large Items
Description:
The team will decide on a maximum “size” for items (e.g 1 person-day of effort). Each item is discussed to determine if it is already that size or less. If the item is larger than the maximum size, then the group breaks the item into smaller items and repeats the process. This continues until all items are in the allowed size range.
T-Shirt Sizes
Recommended for: New teams; Large Backlogs; Early-stage estimation
Teams of: Medium / Large Teams
Items of: Large Items
Description:
Using numbers is the most common approach for estimating points, but sometimes teams find themselves over analysing when trying to arrive at a number of points. If you notice that team members are getting caught up in the idea that the number of points associated with a story has anything to do with the number of hours involved in delivering the value of that story, it may be more effective to switch to a non-numerical system like T-shirt sizing. By removing the implied precision of a numerical score, the team is free to think in a more abstract way about the effort involved in a story.
Items are categorized into t-shirt sizes: XS, S, M, L, XL. The sizes can, if needed, be given numerical values after the estimation is done if this system works for your team or management wanting to measure velocity.
This is a very informal technique, and can be used quickly with a large number of items. Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.
Some teams even adopt creative approaches such as using dog breeds to estimate stories. For example, “That story’s clearly a Chihuahua, but the other one is a Great Dane.” Engaging the fun, creative side of the team while they’re estimating technical stories can be effective at getting them out of their analytical thought processes and into a more flexible, relative mindset.
T-shirt sizes and can be very effective for teams just starting out with agile, eventually it’s a good idea to move the team toward a more rational numerical scale.
Bucket System
Recommended for: New teams; Large Backlogs; Early-stage estimation
Teams of: Large Teams
Items of: Large Items
Description:
This technique goes hand in hand with planning poker in my experience and it’s usually best experiences as an extension of planning poker when there’s a bigger team and more tickets/larger items.
Set out a list of post-it notes on a wall or table following the Fibonacci Sequence/Modified Fibonacci Sequence.
0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 200
The facilitator starts with one task, sets it in the 13 bucket — this is the first reference item.
We will then choose another item at random and after a time-boxed discussion 1 to 2 minutes put the item in the appropriate bucket. And so on and so forth. If the random items have skewed the estimates to one way or the other, realign them (e.g. if the first item is actually very small and should be in the “1” bucket).
Divide and conquer. Allocate all the remaining items equally to all the participants. Each participant places items on the scale without discussion with other participants. If a person has an item that they truly do not understand, then that item can be offered to someone else.
Everyone quietly reviews the items on the scale. If a participant finds an item that they believe is out of place, they are welcome to bring it to the attention of the group. The group then discusses it until consensus is reached and it is placed in one of the buckets.
Which estimation technique is best for your team?
Ultimately the team should choose which is their favorite technique, but you can see how certain techniques are better suited to better scenarios or at times during projects.
I’ve marked out a table below that may help.
I would probably suggest choosing a technique for early-stage and then a late-stage estimation; based on the size of the team and how well established they are, that the team wants to adopt and use these two techniques for your project.
