You think you're better than those silly story points?

Suppose you have a team which estimated a set of new features and was expecting the work to take them 3 months (90 days) then, like any good software project, they launched in 5 months (150 days).

The 90 days represented how long they thought the work would take.  The 150 days represented how long the work actually took.  In the end, the 90 days worth of work took 150 days.

If we mapped the days at the beginning of the project to actual days we would find out that a "day" before the project began was equal to 1.7 days of actual time [150/90=1.7].

The notion that if you only had your estimate in days and not those silly story points it would "be better or more useful" is nonsense.   Knowing that the project was scheduled for 90 days doesn't help you a wink when it comes to doing the work.  "It'll take as long as it takes."  We are hoping that 1 project-day is equal to 1 actual-day.

This is another way of saying the estimate is just a benchmark by which you can measure progress or doneness once you begin the work.  I don't fully understand why teams continue to confuse the estimate with doing the actual work.   As the old saying goes, "No plan survives first contact with the enemy."  In software that saying would be, "No plan survives first contact with implementation."

Teams often want to know how to convert story points to time, but you can't.  Velocity can be converted to time, but you cannot convert story points.   Do a sprint, measure your velocity, and use it to forecast

This can be frustrating if you don't want to wait until you've established a velocity in order to forecast a schedule.  Teams often turn to estimate their features in days, thinking that by using a unit of time to do their estimate, that it will be more accurate.   As the story above illustrates - a day in the estimate might not be a "day" in real life.  Something you'll only discover by doing the work. In the example above 1 "project-day" was equal to 1.7 "actual-days."

One of the reasons teams often switch from days to story points is because quoting features in days can seems too real.  Other people confuse the estimate with fortune telling - expecting the estimate to be real because the estimate was given in "days."  But these estimate days are not real days.  Estimates are given in what's commonly referred to as a "project-day" to distinguish them from "actual-days" or as I like to call them, "days."

There is no difference between using story points or project-days.  The concept of the project-day has been around for ages.

Would it be comforting or disturbing to learn that story points and the Agile methods of estimating are really just different jargon for "earned value management," first put into wide use by the US Government in the 1960s?   It's likely this method of estimating and progress monitoring has been used for thousands of years - and in all those years the plan has always been a bit different than reality.

It's okay.  Whether you use story points or project-days, you need the plan.

Just don't confuse the plan with the actual work.