Why Story Points?

Traditionally, estimations for software development projects were done in the unit of time (i.e. Hours, Days, Weeks, Months etc.). However, its changed now with Agile. In Agile software development we generally use story points. But why?

There must be a significant strong reason of it. Let’s try to understand using this example-

Let’s say I have to travel to Chicago from Des Moines. So before starting my journey I’ve to plan it and first thing I am going to do is ask someone who has already travelled, how long did it take. And I will also verify with another person his experience to get more accurate estimate.

Sunny: “I want to travel to Chicago. Chris how long did it take you to get there?”
Chris: “5 hrs” 

Sunny: “Joanne you were in Chicago last week on a business trip. How long did 
        it take you to get there?”
Joanne: “1 hr!” 

Same distance, so different durations????

Picture says it all!!

We can relate this example to any software project. For the same scope (if we can size it) we may get completely different answers, based on the technology used to implement it (.NET WebServices, Oracle WebLogic), development tools, domain expertise and the skill-set of developers.

Even in this simple, linear example, travel from Des Moines to Chicago, there are many variables that may change duration 700% percent for the same size (i.e. 330 miles) like -

• Different vehicle (technology), airplane, truck, bus, car.
• Familiarity with the road (domain expertise)
• Driving ability (proficiency). For instance, Michael Schumacher probably can drive this trip in 3.5 hrs, my mother in 7hrs

So now we know the reason of not doing estimations for software development projects in the unit of time.

So what else should be the approach? Before finding the answer, lets have look on sizing.

There are two ways for sizing: 1) Absolute Sizing, and 2) Relative sizing.

If we put an apple or orange on a scale, we would know their absolute size i.e. weight in grams.

However, if we just want to compare which one is heavier, we can put them on the balance scale. We call it relative sizing, comparing one to another.

Software is "intangible". Is is possible to find the "absolute size" of it? 

Well, the answer is yes, and it could be done with Function Point Analysis (FPA). 

Function Point Analysis claims, that regardless of technology or programming language used, proficiency and expertise of developers, two or more certified FPA analysts would estimate the same project within the reasonable margin of error! 

That is very encouraging claim! Even more, as of 2012, there are five recognized ISO standards for functionally sizing software. 

However FPA requires a detailed requirements. 

In Agile, user stories are intentionally vague, therefore FPA (absolute sizing) is not good match for them.

Now question comes how would we measure while doing relative sizing?

There are two very common approaches for it:

1.  Story points (1, 2, 3, 5, 8, 13..)   
2.  T-shirts size (S, M, L, XL …) 

There is one limitation in using t-shirt size i.e. we can’t perform mathematical operations. Using numbers its easy to do addition, multiplications etc. That’s why story points have a preference over t-shirt size approach.

Please refer to next blog expelling more about assigning story points in to a story. Here is the link -

Thanks for your time.