Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)


What are Story Points and why use them?

Posted by Chris Adams

Article Rating // 29722 Views // 3 Additional Answers & Comments

Categories: Business Analysis, Systems Analysis, Agile Methods, Project Management


Story points are a unit of measure used to estimate the relative size and complexity of user stories in agile development.  If one user story is 1 point and another is 2 points then the 2 point user story is expected to take twice as much effort to develop as the first.

Sample Product Backlog Estimates

  • User Story #1 - 4 points
  • User Story #2 - 1 points
  • User Story #3 - 2 points
  • User Story #4 - 2 points
  • User Story #5 - 8 points

So, why not just estimate in hours? The answer is in how the human mind deals with numbers.  

There are two primary examples to consider.  First, we don’t estimate things to take 26 or 27 hours.  Instead, we say a task might take 24 hours because we convert this in our minds to 3 work-days. Or we might even give an estimate of 20 hours which makes us strain just a bit harder and think in terms of half work-days, but we are willing to do the mental conversion because we feel its worth the additional granularity. Second, if I ask you to tell me whether a specific task will take 26 hours or 27 hours, you probably couldn’t reliable say either way.  A difference of 1 hour when the entire task takes around 26 hours feels negligible. 

These two examples are reflections of two challenges:  

1) Anything over about 8 hours of effort causes us to begin doing mental math to internalize the amount of time involved.

2) When numbers grow in size we have difficulties having conviction in our estimates.  How can you make a strong argument to management that a task, feature, or user story will take 56 hours rather than 48?

Story points solve these problems by normalizing estimates around a unit of 1 story point.  So, the smallest user stories may take 1 story point of effort to complete while harder ones may take more (2, 4, 8, etc.)

This immediately solves our first problem, since I no longer have to convert estimates during the estimation process.  I’m making relative comparisons of overall complexity and effort.  The human mind lives in the domain of relative comparisons.  So, it’s much easier for our brains to determine that one user story is about twice as big as another than to say one will take 16 hours and another 32 hours.  So much easier, in fact, that some companies have found that by estimating projects in terms of story points their time spent on project estimation has reduced by 80%.

Story points also solve our second problem of both defending and having conviction in our estimates.  Since we are dealing with story points, as estimates get larger we don’t worried about maintaining the same level of granularity as we might if dealing with hours.  We don’t size user stories in half story points.  In addition, management is less likely to argue that a particular user story should be 2 points versus 4 points.  However, if they are reviewing estimates in hours, all too often they will argue that 80 hours “seems to long” for a particular piece of work.

Chris Adams
LinkedIn Profile



BAPA posted on Friday, October 19, 2012 10:09 AM
So eventually each story point has to be linked to a certain number of hours, correct? If so, who decides how many hours are to be allocated per story point? How do you decide that?
Chris Adams posted on Friday, October 19, 2012 5:36 PM
You don't actually have to ever convert the story points to hours if you don't want to. Again, the goal of story points is to decouple the estimation effort from hours. It's a nice way to do relative sizing, i.e., something is twice as big and complex as something else.

Initially, the development team would take the highest priority user stories and code them in the first iteration. However many story points they complete is their velocity. So if they coded 5 user stories totaling 24 story points, then they would know that in future iterations they could complete around 24 stories points plus or minus a few.
Chris Adams
Umesh posted on Wednesday, August 28, 2013 11:03 AM
I am not convince, If Management ask how much time will take to fix a bug in software and I say, It is 8 story point. They will not understand any thing out of it and they will again ask about estimated time to fix a bug.
Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.



Select ModernAnalyst Content

Register | Login

Copyright 2006-2023 by Modern Analyst Media LLC