Seth Eliot's Blog

Most agile software teams choose to define User Stories as the increment of value they deliver, with a given release or product comprising multiple of these stories. To figure out what they can do and when, teams need to estimate these stories. Estimating, using time units such as days, person-days, or ideal-days is a big mistake. You should instead use unit-less story points. Here is why.

 
 

Unit-less story points are better than estimating in time units

Relative estimation is easier than absolute estimation

If I were to ask you how tall is the Empire State Building in NYC, could you tell me in feet or meters? By asking for a measurement with an actual length unit, I am asking for an absolute estimate. (similarly asking for time in days is also an absolute estimate) But what if I showed you the diagram below and asked you how tall it is relative to the ‘Great Pyramid”? You could answer that it is about three times as tall as the pyramid. Similarly you can say the Eiffel Tower is about twice as tall as the Great Pyramid. These are relative estimations, and we tend to be a lot better at making these than we are at absolute estimations.

The way this works with stories is you pick several small-ish stories you have already completed, and you assign them one or two story points, where the two-point stories are about twice as big as the one-point ones. Now you have a baseline with which to measure stories you have not yet started. Going-forward, pick a new story to be estimated and if it is twice as big as a one-pointer, assign it two story points. If it is twice as big as a two-pointer, assign it four story points. Keep in mind for every team, story size will mean different things depending on what baseline they chose.

 
 

Time depends on who is doing the work

 Another reason not to use time base estimation is that a veteran developer who has been on the team for years will likely be able to complete a story in a fraction of the time it would take the new intern. So calling a story a 3 day story is meaningless — is it 3 days for the pro or 3 days for the intern? Instead we should measure story size using story points.

 
 

How it works in real life

What do we mean by “size”?

We are measuring story “size” but what does that mean? It is not time, otherwise we would just be referring to time by another name. Size is a measure of scope and complexity, and therefore ultimately effort. Yes this will correlate to time, but as we previously discussed time will vary depending on who is doing the work. With size we are attempting to capture a measure independent of who does the work.

 
 

But we need to ultimately know time

We do ultimately need to know what will be ready for release and when it will be ready. Our stakeholders are often keenly interested in release and availability dates. This information can be calculated from your story points. Just look at what your team has historically delivered — add up the story points for all stories completed by the team and calculate how many points the team delivers over time. This is called velocity (or delivery rate) and tells us what the team is capable of doing. We can then look at all the stories that remain, and add up the points for all those stories. Using the velocity we can then calculate how much time it will take to complete all those stories. In other words:  

Time to completion = Remaining points / Velocity (in points per time)

Of course this is the simplified version. For more details, see this.

 
 

Story points can be fun

Many teams choose to make up fun units rather than use generic story points. One team I know uses “aspirins”, since the bigger a story is, the bigger headache it can be. Other teams use “jelly beans” or “gummy bears”.

 
 

Some best practices

Estimate as a group

Group exercises like Planning Poker enable you to engage the whole team, bringing the power of collaboration to your estimates. When doing group estimation be sure to use methods where everyone estimates simultaneously. Otherwise the first person to speak will create an anchor bias in subsequent answers from other folks in the group.

 
 

Avoid false precision by using an increasing sequence –

When assigning story points you should use a sequence with increasing gaps between consecutive numbers. Many teams use powers of two (1, 2, 4, 8, 16…) or a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…). The reason for this is that a small story is easier to understand and leaves less room for estimation error. As a story gets bigger your estimate will be less precise. Therefore deciding between 15, 16, or 17 story points is meaningless – in this case you would assign 16 and move on

Ease of estimation is one reason you should favor smaller stories, and when a story estimates as big, you should try to break it into smaller stories. Another reason to favor small stories is that you will finish them quicker. You will be able to show value to your stakeholders more often and get feedback to keep your project on track.

 
 

Getting started

The above information is all available elsewhere on the internet, but I could not find a single citation that discusses all the points above together. Now with all this info in one place, you can now get some ideas on how to proceed with your team. As you do, you will need more details and for those you can search and dive-deeper on each issue I mention above.

 
 

Thank you to Ed Tellman and Alex Zotos who helped me with this blog.