Effort estimation is atopic that keeps bothering our industry and unfortunately i don't think we were still able to "nail it". Perhaps we can't. Perhaps we don't need to. 
When working with my clients i keep getting questions about the topic, the following post is an unedited version of one of these questions.

I got an email from the CEO of one of my customers, he was inquiring about story point usage and i liked my response so much i decided to share it “as is” with the hope you will find this useful for understanding and explaining the concept.

The original email:

On Thu, Dec 3, 2015 at 3:38 PM, XXXX YYYY <XXXYYY@CCCC.com> wrote:


Can you please give me your opinion wether points should be somehow ‘softly’ mapped to time. So when a team is planning, they think about a point is a day… or whatever. 

The current situation looks unpredictable.


My response:

On Thu, Dec 4, 2015 at 9:12 AM, Elad Sofer <elad@practical-agile.com> wrote:

Dear XXXX,

In my opinion points should not be mapped to days, points are mapped to points only, and when estimating a PBI (product backlog item) we compare it to other PBIs and try to assess wether it is of the same size, bigger or smaller and if so with what ratio. 

Points are a measurement of progress:

Using point to measure progress is not the same as measuring time, progress reflects many other parameters such as defects rate, errors in estimation, rate of people being sick, team mood, time spent helping other teams etc...

The way points work for us is that we derive time calculation using the actual empirical data which we call velocity. 

Here is an oversimplified example:

Let assume a team estimated several PBIs, and the total of the PBIs is 100 points.

After finishing the first sprint the team was able to complete (meet DoD) PBIs with a a total of 20 points.

We now say the velocity of sprint 1 is 20, so we can assume that based on this data it will require 4 more sprint to finish the remaining 80 points.

Based on past data (and possibly other input), on the 2nd sprint the team planned for 20 points, at the end the team was able to complete PBIs with a a total of 10 points. this can happen for various reasons as explained above.

We now know that the velocity was 10, and that the average velocity is 15, so we can assume we need 5 more sprints to complete the remaining 70 points.

And so on... 

So, why do we use this method of estimation?

  • We use points to reflect progress.
  • We use points as a mirror and indicator to know when things may have gone wrong.
  • We use points to simplify estimation and avoid spending too much time on things that deliver relatively low value.

What points should not be used for?

  • We do not use points to evaluate team productivity.
  • We do not use points to evaluate team performance.
  • We do not use points to compare teams.

From my personal experience, once a team (and product) learns how to properly use relative estimation, the predictability increases, at least to the level of the defined DoD.

I hope that answered your question,