Agile Estimation:: Story Points

Agile estimation story points

There are many ways to estimate development projects such as human hours, Dot Voting, T-Shirt Sizes, and so on and so forth. One way is by using Story Points. Estimating with Story Points offers advantages to developers and clients.

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

Story points were developed as an alternate system for estimates. Instead of estimating how much time work will take to finish, story points are an assigned value that looks at how long it will take to finish a piece of work in relation to other pieces of work.

Story points are therefore relative measurements/metrics/measures, and unitless, unlike time estimates.

Story Points include:

  • The amount of work to do - EFFORT.
  • Complexity of the work - COMPLEXITY.
  • Any risk or uncertainty in doing the work - RISK.


Agile estimation story points example with buildings

Our Team should build all of these buildings (it is our project).

The team ought to estimate the project using story points.

Firstly, The Team has to choose a reference building, the smallest building all of them. It is a HOUSE. An Estimation of building HOUSE is one (1) Story Point.

Secondly, The Team estimates all buildings in relation to the reference building - HOUSE

London Eye Estimation is 13 Story Points since London Eye is 13 times complicated (more amount of work, more necessary effort, and higher risk) than the House.

The others estimation - please have a look at the picture

The main idea is to choose the easiest feature in relation to others (reference features) then estimating other features in relation to the reference feature.


A good way to make sure story points stay fixed and relative is to use the Fibonacci sequence. The Fibonacci sequence is a sequence where any individual number is the sum of the two numbers that precede it.

The story points sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100


Agile estimation story points example with buildings

In planning poker, each member of the team gets a set of playing cards with the allowable story points printed on the front as well as extra cards for don’t know (?), infinity or, sometimes, to indicate it’s time for a coffee break for instance.

Once the story/feature is ready to be estimated, there is a round of voting. At the same time, all team members hold up the card which corresponds to their estimate.

  • If all the team members agree then the story/feature is given that number of points and the team moves on.
  • If there are discrepancies then Scrum Master facilitates a discussion where team members can further explore what’s required, investigate acceptance criteria further etc. There is then another round of voting and this repeats until the consensus is achieved.

A good technique to estimate a very small number of stories/features from 2 to 10


The bucket system

The “Bucket System” is a way to do an estimation of large numbers of items with a small to medium sized group of people, and to do it quickly.

The Bucket System of estimation works as follows:

  1. Set up the physical environment as per the picture below. Ensure that all the story/feature to be estimated are written on cards.
  2. Choose an story/feature at random from the collection. Read it to the team. Place it in the “2” bucket. This story/feature is our first reference item.
  3. Choose another story/feature at random from the collection. Read it to the team. The team discusses its relative position on the scale. Once consensus has been reached, put the story/feature in the appropriate bucket.
  4. Choose a third story/feature at random and, after discussion and consensus is reached, place it in the appropriate bucket.
  5. If the random story/feature have clearly skewed the scale towards one end or the other, re-scale the story/feature (e.g. if the first story/feature is actually very small and should be in the “1” bucket).
  6. Allocate all the remaining stories/features equally to all the participants. Each participant places stories/features on the scale without discussion with other participants. If a person has a story/feature that they truly do not understand, then that story/feature can be offered to someone else.
  7. Everyone quietly reviews the story/feature 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 the consensus is reached and it is placed in one of the buckets.

The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated from 50 to 500 (but there can be fewer items)

Agile estimation techniques are collaborative. All appropriate people are included in the process.

Enjoy! Be Productive not just busy!