Get certified - Transform your world of work today


Agile Estimation Techniques

18 January 2016

Vikram Singh

One of the key advantages of adopting an Agile work flow is the team's ability to estimate new work effectively.

Over time, as team members encounter new user stories, they should develop an increasingly accurate sense of how they're going to approach stories and how much effort each user story will take to complete. Getting everybody on the team involved in the estimating process is critical to arriving at accurate estimates that reflect the true understanding and investment of the team.

Unless all team members participate actively, the ability of the team as a whole to estimate new stories will develop much more slowly.

Here are some methods I learned during a Certified ScrumMaster® training program. You can try a new method in each sprint.

Planning Poker®

Planning Poker is a game that team members can play during planning meetings to make sure that everybody participates and that every voice is heard.

To begin, each team member is given a set of cards with numbers on them. The numbers are usually ordered from 0 to 21 using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21.

Then, each story is read aloud. After each story is presented, everybody on the team is asked to hold up the card, showing the level of effort that they believe this story represents for the team. Initially the estimates may be all over the map. But after a while, the team will get a sense of how much effort they all estimate is associated with a typical type of story. Once all the votes are in, the team members with the lowest and highest estimates explain why they chose their scores.

Frequently, experts with detailed knowledge may be able to tell the rest of the team why a certain story is actually much easier than they thought, or why it may be more difficult than it first appears because of unexpected requirements. Through this process, everybody on the team learns more about what's involved in estimating stories both inside and outside of their specialties, increasing knowledge sharing across the entire team.

With Planning Poker, the numbers are significant. A story estimated as a 2 should be about one fourth as difficult as a story estimated as an 8. Stories estimated at 20 or higher may be so large that they need to be broken up into smaller stories before they can be attempted. Stories estimated at 0 may not even be worth tracking.

Online Planning Poker tools

Below are some of the Planning Poker tools available online for estimation:

Bucket System

The Bucket System is a way to estimate large numbers of items with a small- to medium-sized group of people, and to do it quickly. The Bucket System has the following qualities that makes it particularly suitable for use in Agile environments:
  • It's fast! A couple of hundred items can be estimated in as little time as one hour.
  • It's collaborative. Everyone in a group participates roughly equally.
  • It provides relative results, not absolute estimates (points vs. hours).
  • The results are not traceable to individuals and so it encourages group accountability.
  • Works with teams to estimate effort or with stakeholders to estimate value.
The Bucket System of estimation works as follows:
  1. Set up the physical environment, as per the diagram below. Ensure that all the items to be estimated are written on cards.
  2. Choose an item at random from the collection and read it to the group and place it in the "8" bucket. This item is our first reference item.
  3. Choose another item at random from the collection and read it to the group. The group discusses its relative position on the scale. Once consensus has been reached, put the item in the appropriate bucket.
  4. Choose a third item at random and, after discussion and consensus is reached, place it in the appropriate bucket.
  5. If the random items have clearly skewed the scale toward one end or the other, rescale the items (e.g., the first item is actually very small and should be in the "1" bucket).
  6. 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.
  7. Sanity check! 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.
  8. Write the bucket numbers on the cards so that the estimates are recorded.

T-shirt size

Occasionally team members align the story points with the hours of effort, which can create confusion. To avoid this, it may be more effective to switch to a nonnumeric estimation technique.

Teams who don't enjoy playing with numbers that much use T-shirt size as another popular technique. So when the teams tend to overanalyze the numbers, T-shirt sizes come in handy, as T-shirt sizes are easier to relate to.

With T-shirt sizing, the team is asked to estimate whether they think a story is extra- small, small, medium, large, extra-large, or double extra-large. 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.

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.

There are some practical issues to consider when adopting T-shirt sizing for story estimation. For one, non-numerical scales are generally less granular. Although that can speed the voting process by reducing the number of options, it may also reduce the accuracy of velocity estimates.

In addition, the ability to compare stories with each other can be a little bit more complicated, because there is no clear mathematical relationship between a medium and an extra-small. T-shirt size scales also require extra effort on the part of the person coordinating the Agile process. The T-shirt sizes need to be converted to numerical values for the sake of tracking effort over time and charting an estimated velocity for the team. For this reason, while T-shirt sizes 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.

Relative mass valuation

When adopting Agile as a new technique for a team, frequently there will be a large backlog of stories that need to be estimated all at once.

One of the biggest advantages of Agile estimation is that stories are estimated relative to each other, not on the basis of hourly or daily effort. It's usually clear to a team, regardless of their level of experience, if one story is going to be more difficult than another, even when nobody has any idea how long it may take to complete individual stories. But going through the process of individual point estimation for a huge list of stories can be daunting.

Relative mass valuation is a quick way to go through a large backlog of stories and estimate them all as they relate to each other. To use this approach, first write up a card for each story. Then, set up a large table so that the stories can be moved around easily relative to each other.

Start by picking any story, then get the team to estimate whether they think that it is relatively large, medium, or small. If it's a large story, place it at one end of the table. If it's a small story, it goes at the other end of the table. A medium story goes in the middle. Now select the next story, and ask the team to estimate if it's more or less effort than the story that you just put down. Position the story card on the table relative to the previous card, and go to the next card.

By using this technique, it's possible to go through 100 or more backlog stories and estimate their relative effort in as little as an hour. Everyone on the team will feel a sense of accomplishment when they see the scope of their work laid out in front of them, estimated in order of effort.

The next step is to assign point values based on the position of the stories on the table. Start with the easiest story that is worth assigning points to, and call it a 1. Then, move up the list of cards, assigning a value of 1 to every story until you get to one that seems at least twice as difficult as the first one. That story gets a 2. You may need to remind the team not to get caught up in the fine details. The idea is to get a rough point estimate, not a precise order.

Ultimately, any story may be completed in any order based on the business value and priority assigned by the product owner, so all the team needs to estimate is how many points one story will take relative to another.

Dot voting

Dot voting is a technique that allows participants to vote their preferences among a set of items by placing a colored dot on items that they believe are higher priority than other items. Items with more dots are higher priority than items with fewer dots. This technique is frequently used during the sprint retrospective activity.

Dot voting is effective for ranking multiple options. All individuals have the same number of votes, represented as dots, which they can spread across one or more distinct options. Each item on the list has to be granular and well understood by everyone, and then the voting begins.

For example, perhaps there is a list of ten items identified in a retrospective, and the team wants to narrow the list to a couple they will work on. Everyone has three dots to vote on the retrospective items. Some will put one dot each on three different items, others might choose to put all three dots on one option, or perhaps two dots on one option and one on another.

Teams often use stickers and take turns applying them to a list of choices on a flip chart, or they use dry erase pens on a whiteboard to create their dots. There are electronic versions for distributed Agile teams. In many cases, a single round of dot voting will identify the top ranked choices. If not, multiple rounds of voting can be used as the list gets shorter.

The method is summarized as follows:
  1. Post the user stories on the wall by using yellow sticky notes or in some manner that enables each item to receive votes.
  2. Give four to five dots to each stakeholder.
  3. Ask the stakeholders to place their votes. Stakeholders should apply dots (using pens, markers, or, most commonly, stickers) under or beside written stories to show which ones they prefer.
  4. Order the product backlog from the most number of dots to the least.
When you are done with this first pass, it is almost certain that the stakeholders will not be completely happy with the outcome of the vote. If that is the case, you should review the voting and optimize it. Here's what you can do:
  1. Arrange the votes into three groups to represent high, medium, and low priorities.
  2. Discuss stories in each group.
  3. Move items around to create a high-priority list.
  4. Make a new vote with items in the high-priority list.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.4 (5 ratings)


Senthil kumar Ponnusamy, CSM, 1/18/2016 11:43:18 PM
Good one. just wanted to add some points here. A little effort helps a lot and A lot of effort only helps a little so general advise that don't take too much time on estimation otherwise the accuracy will be reduced.
Senthil kumar Ponnusamy, CSM, 1/18/2016 11:46:00 PM
also it will be good to consider below points as well when we do estimation:

Volume - How much is there?
Complexity - how hard is it?
Knowledge - What do we know?
Uncertainty - what's not known?
Tim Baffa, CSM, 1/19/2016 8:40:23 AM
Thank you Vikram.

A few corrections and comments.

- Planning Poker: Sometimes, the "outliers" (high and low estimates) can provide information that the rest of the team had not considered. And it isn't the responsibility of the expert to tell others why their estimate is wrong.

- Planning Poker: The Fibonacci sequence illustrates a scaling order of magnitude; therefore, a 2 is not 1/4 as difficult as an 8. You simply need to understand that a 3 is more difficult than a 2, a 5 is more difficult than a 3, and an 8 is more difficult than a 5. You should never apply hard math to Fibonacci estimates.

- Bucket System: Why start out with a specific number, like "8" (bullet #2)? Just pick a starting story, and have everyone allocate the other stories as explained. Then you should have 4-5 categories of stories (never more than 6). This is because people cannot differentiate more than that. THEN set your Fibonacci scale on the categories at whatever the team desires.

- TShirt Sizes: They represent the same "Order of Magnitude" approach as applying numbers. There should not be a mathematical relationship in any relative estimation!
Senthil kumar Ponnusamy, CSM, 1/19/2016 9:37:30 AM
Thanks Tim. it is useful
Vikram Singh, CSM, 1/19/2016 10:56:31 AM
Thank you, Tim and Senthil for comments.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up