Story points vs. Hours...

Ok, follow along with me because it will take a bit to get to the punch line. 

You and 3 people are asked to estimate the work to mow a lawn.  All of you estimate the effort as a 3.  So far so good. 

You are a professional greens keeper and were planning on using a riding lawn mower, gas powered edger and backpack blower. 

Person A is a high school student that mows lawns to supplement his allowance.  He has a gas powered push mower and that is all. He never even considered edging or cleaning up the loose clippings as part of the work.

Person B is a 50 year old homeowner that has been mowing his yard for 25 years.  He has a gas powered mower, an electric "weed-eater" he will use to trim the lawn. He has a large broom and dust pan he will use to clean up.

Person C is the grandmother of the high school student who has never actually mowed a lawn but has watched her husband, son, grandson and neighbors do it for years.

So while all of you can agree that the effort to mow the yard is a 3, how do you agree on the time it will take?  And does it really matter how long it would take as long as the value of a freshly mowed lawn is delivered? Isn't the goal of it all to deliver a mowed lawn?  You aren't trying to deliver 8 hours of work.  You are delivering a mowed lawn. 

Using Story Points to judge a teams performance is a fallacy in my opinion.  Story Points are only a way for Development Teams to estimate effort and relate one story to another.  When they get to the point of planning a sprint it should be done based on how the stories chosen come together to form a increment of value.  Teams performance should be based on how often value is delivered and how significant that value is to the stakeholder. If a team of 5 can take 15 hours to deliver a increment of value estimated at 8 that will allow a company to increase revenues by $1,200,000,  is that bad? What if that same effort was estimated by another team at a 20 and it took them 48 hours.  Which one is bad and which is good?  In the end, both teams were able to increase revenues by $1,200,000.  Isn't that what you really want?

but where does the actual time come into play..?

Where does the actual time really need to come into play if value is being delivered?

where does the actual time come into play..?

The purpose of estimation is to help a team figure out how much work it can take on. A Scrum Team might forecast how many story points they can accommodate in a Sprint based on prior experience, for example.

Each Sprint is a regular recurring time-box. It allows like period of time to be contrasted with like so empirical process control can be established.

So we all know that story points represent the 'effort' required by the team to complete a user story (or however you want to word it)... It is, by definition, the collective estimation of the team. Story points equal velocity and all that... So, all members of the team (experienced, junior, etc.) provide their input and come up with their estimate. Using the FS, 1, 3, 5, 8, etc.

Make sure you say RELATIVE effort when ever you are talking about Story points ! It is not right to use the word effort in the context of story points as Story points is the measure of RELATIVE EFFORT ! Since it's relative it doe not have any time unit. 

...it's more accurate to estimate things...

Did you notice the irony in this statement? 

Accurate = correct in all details; exact.

Estimate = an approximate calculation or judgment of the value, number, quantity, or extent of something. 

You are trying to make your estimate accurate ?!! This mindset is the reason why it is so hard to explain this simple fact of RELATIVE ESTIMATION to the agile teams.

Otherwise how will you ever know how long things will take to complete in real terms?

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. - Scrum Guide 

You will know how long things will take based on the how many points your team (provided the capacity is intact by following the dedicated no changing team composition principle is met) can produce on an average for each sprint and knowing how many points are still left in the foreseeable (most of the relatively estimated in story points) backlog. When the SAME TEAM, with the SAME ESTIMATION TECHNIQUES are estimating for the SAME KIND OF WORK, the team usually tends to call a 1 a 1 and a 3 a 3. For example just after 2 Backlog review sessions you will notice that your teams pick the same numbers for similar items since they have already practiced considering all aspects w.r.t the acceptance criteria and definition of done while estimating the backlog items. So they know what kind of items are the smallest (1s) and what are the next level (2s) ad the next level (3s). As the team gains experience in RELATIVELY comparing the PBIs they will seldom use 5s  or 8s !

Note: RELATIVE estimation is simply COMPARING the size w.r.t to each other. The best starting excercise I can propose is as below.

1. Find the smallest ones and mark them as 1 for now
2. Now find the next unmarked item and see if it is big and how big RELATIVELY
3. If you think it takes double the effort mark it as one, if you think it takes more than that mark it as 3
4. Continue this process and identify the 8s and try to break them into smaller PBIs so they are COMPARABLE in size to the smaller PBIs
5. NEVER try to measure them in hours. At the end of the sprint you will REALIZE how many points are done
6. Since the same team picks PBIs for the next Sprint that are RELATIVELY estimated by the same method they will now know how many points to consider.
7. With each sprint this forecast will get better.
8. Once you have established a consistent velocity (number of points delivered per sprint) you can easily extrapolate how much backlog can be delivered (provided its relatively estimated already) by when for the same team with same capacity (allocation of resources) 

In my opinion, there are two points to always remember regarding relative estimation:

• As Uma pointed out, we are talking about estimations.   Estimations are inherently "best guesses", and it is foolhardy to associate any level of exactness to estimation.   The goal should always be around continuous improvement of estimation accuracy, while at the same time understanding that estimation is an imperfect science
• The reason for Relative Estimation is rooted in scientific studies which identified that, while those in IT were very poor in providing accurate time-based estimates for though-based work, they actually excelled in being able to determine whether one thought-based work item was larger or smaller than another one.   Hence, relative estimation was born, to take advantage of this ability, and avoid a practice (time-based estimation) that was very inaccurate most of the time