Agile Estimation: 9 Reasons Why You Should Use Story Points

by Avienaash Shiralige

A common question about estimating with points is, “Why Points?  Why not in Days? Finally I need to do planning so I need to convert points to Days. Why this additional level of indirection?

In-fact I find story points as a good distraction to the team. Let me go over why having this “additional layer of indirection” provided by story points can be very useful.

1. Points make it compulsory to use team’s performance data (velocity) for release planning.

  • More accurate way. Don’t you think so? Before the project’s first sprint, the velocity number is also an estimate or a prediction.  But as soon as the team has run even one sprint (a couple of weeks into the project), the velocity represents measured data about how much that specific team can actually produce.  Running 3-5 sprints gives you even better data. A data which takes into account all of the factors affecting delivery on that team.
  • Planning can only be performed by knowing or predicting the team’s velocity.  Thus, using points forces all planning to happen through the lens of the team’s velocity. All subsequent planning about how much will get done in a sprint or a release can and should take this data into account.  If the team is estimating and planning with points, this will happen automatically as points force you to consider velocity.
  • If days are used as the estimation unit, however, it is all too easy to revert to planning in terms of “person days” available.  Using only days for future planning without looking through the lens of velocity ignores the best data available about what will actually get done.

2. Prevents the need for frequent re-estimation. Works like a size-based estimate.

  • In planning with points and velocity, rather than with days, we are essentially treating points as a size-based estimate.  This prevents the need for frequent re-estimation, because we don’t expect size of the story to tell us how much time it will take to complete it.
  • Days, on the other hand, are difficult to use as size-based unit, simply because the word “days” strongly implies elapsed time.  One intuitively expects that a “two-day” story will be done in two days.
  • With iterative development, the team is constantly learning more about what they can do and about how long it takes to do certain kinds of work.  If estimates are in days, the team finds itself in the position of needing to frequently re-estimate future stories based on current knowledge.  If the team’s ability improves to the point that what used to take two days now takes only one, unimplemented stories with a “2 day” estimate should be changed to “1 day”. This problem largely goes away with points.  The fact that a team has learned to work twice as fast gets reflected in their velocity.  As long as the story sizes are consistent (read my earlier post) between stories, no re-estimation is necessary for planning to occur.

3. Teams talking about “days of work” implies a level of specificity that isn’t real.

  • Using points and velocity makes planning real. Focuses the conversation on “How well is the team as a whole performing?” rather than “Why team is taking so many days? or Can we finish these stories in 3/4 time” etc

4. Story Points allays fear of commitment

  • Hence developers are much at ease(less stress) while estimating.When people are under less stress they think more rationally and hence better estimates. Because when you estimate in days, since days means elapsed time, a fear of whether I can finish in this time starts creeping in.

5. Focuses client conversation on the right questions if client is Agile or at-least understands Agile.

  • Communicating with the client tends to be easier and more honest when using “points” rather than “days”.  This is because points allows us to separate the two concepts of how much work is to be done vs. how long it takes to do that work.
  • When a team presents its estimates in terms of time (days) it is easy to mis-communicate about how that effort maps onto calendar days.  When the team instead talks in terms of points, it is immediately obvious to all that a conversion must take place again, using the team’s velocity in order to figure out how much work can be done.

6. Story Points invites collaboration as team behavior becomes prominent over individuals.

  • Using planning poker to estimate story points brings team together.  It acts as team building activity as teams share, constructively criticize each other, debate and have fun playing poker cards to come to consensus on estimates.

7. Story Points help drive cross functional behavior.

  • Mike Cohn explains this very well in his book Agile Estimation and Planning. Agile teams include people from different discipline like programmers, analysts, testers, designers, product owners and so on. Agile Projects will benefit when each team member thinks about feature which is built first and as specialist contributor second. Hence estimating in story points help teams learn to work cross-functionally.
  • Since story point is a single number, they all need to think what they are estimating from a big picture and as a feature as a whole. They need to shun their departmental mindset of how much programmer or tester or UI person would take and trying to add the estimates.

8. There is credible evidence that humans are good in relative estimation compared to absolute. [Lederer and Prasad 1998]

9. Story-points estimation is typically faster.

  • Teams who estimate in days have a tendency to take discussion few levels deep. Once again fear of commitment plays a role here, because you are estimating in days.
  • As per Jeff Sutherland, one of the CMMI level 5 company determined that story point estimation cuts estimation time by 80% allowing teams to do other productive project activities.

Overall, using points keeps the planning honest. May be you have more other reasons to share. Eager to hear your thoughts in the comments.

Spread the love
hala June 25, 2012 at 8:18 pm

Great post, Avieenash. I think one thing to note is that stakeholders and management need to be educated on thinking about team deliverables, productivity, and outputs in a completely different way. Story points help give a sense of complexity and delivering actual business value, vs. looking at the team’s work as chunks of output produced within specific chunks of time.
hala recently posted..The Power and Beauty of Community

Avienaash Shiralige June 26, 2012 at 9:42 am

Thanks Hala. Management have to understand and change their mindset towards more Agile way of thinking. They need to appreciate what Scrum has to offer which is so natural and common sense. Hence in organization wide agile transformation one of the biggest roadblock is how to change management mindset. Story point are very easy to follow and implement.No complex thinking or mathematical formulas required to arrive at final number. Once again agile principle of simplicity must dawn on people.

Ruby Garage March 10, 2017 at 7:51 pm

Thank you! I used your arguments for explanation to my team.

Amanda Fong July 5, 2012 at 7:35 pm

Thanks for a great post! I’m going to re-share it with our community on Facebook. 🙂

Right on about how points can help team estimate be more honest and accurate. When using days as an estimate, the team could stress as they are about to use up all the time allocated for their items but aren’t close to finish. I find that on the long run, if estimations keep being inaccurate, it could really down the morale of the team.

Avienaash, what do you think about using hours? I think that it’s a nice compromise between days and points is to use hours. It’s still a unit of time unfortunately, but because hours are smaller units, it allows each individual to estimate slightly more accurately to reflecting his own work capacity. Moreover, since hours are smaller units, overestimating will skew planning less.

Amanda Fong
Community Manager at

Avienaash Shiralige July 6, 2012 at 8:19 am

Thanks Amanda for visiting my blog. I am glad you liked this post.

In points based estimation you don’t strive towards accuracy. Because estimate is, Estimate; it’s not Guarantee. Because we know from all decade that you can’t be accurate at all. Instead what relative sizing brings to us being consistent not accurate. Velocity is a great equalizer and it will take care of any deviations and will normalize team pace.

Story points are useful when do you use it for release planning as per my experience and for iteration planning team can go for day/hours as requirements are more clear. During release planning requirement are vague hence coarse estimation technique like points makes sense.

I would not be in favor of using time factor directly in release planning because of few reasons I have quoted in my post.



Venkatesh July 5, 2012 at 8:14 pm

Good points Avieenash.
Venkatesh recently posted..How to be an effective Scrum Master by understanding the Ego states

Avienaash Shiralige July 6, 2012 at 8:06 am

Thanks Venkatesh.

Vijay April 11, 2014 at 11:28 am

Great explanation. I find it so difficult to explain this point and your articles explains it so easily. Its a culture shift to think in a complete different way.

Vijay April 11, 2014 at 12:13 pm

But on the other hand senior mgmt still wants to know when the project will go live… how do you answer that?

Comments on this entry are closed.

{ 2 trackbacks }

Previous post:

Next post: