Scrum Points: Why Story Points Are Better Than Hours

IMG-6 by

In Scrum, many people who have managed projects with hours have a hard time understanding why story points are better.

Scrum Points: Why Story Points Are Better Than Hours | OpenView Labs

They have failed to understand some fundamental data that has been published for over 20 years in the industry literature.

First, let’s look at the latest data on project failures. [Last year], failure rates increased for IT projects during the disruption of the global financial system. A Standish group survey showed that 68% of projects failed to meet original estimates. In fact, Forrester Group research shows this as well:
Common Project Management Metrics Doom IT Departments to Failure

Looking for more Scrum tips from Jeff?

Check out our exclusive videos below, and be sure to view our Scrum Resource Guide for even more information.

None of this information is new. The venture capitalists I work with say they’ve never seen a correct Gantt Chart in a board meeting. When they dig down into the problem, they say none of their management teams knew the velocity of their teams before they implemented Scrum. Not knowing the velocity of team production is the root cause of 100% failure of [accurate release plans] in their board meetings.

You would think this data would cause people to change their behavior, but many companies seem to prefer to continue to fail and be acquired or go bankrupt rather than improve their project management techniques. The research clearly shows that humans are not good at estimating hours and practical experience repeatedly confirms the research.

The management metric for project delivery needs to be a unit of production. Production is the precondition to revenue, and companies say they are in business to grow revenue and margins (even though in project planning they often do the opposite). At least a venture capital group is clear that it is all about the money, and money comes from velocity of production combined with quality of the product. Hours are expense and should be reduced or eliminated whenever possible.

The best data on individual developer performance comes from Yale University and has been reported previously on my blog. The best developer on a project takes one hour to complete a task while the worst developer takes 10 hours (within a project) or 25 hours (across projects). For teams, the difference is an order of magnitude greater. Larry Putnam’s published data shows that an hour for the most productive team turns into 2,000 hours for the least productive team.

Hours completed tell the Product Owner nothing about how many features he can ship and when he can ship them.

The metric of importance is the number of story points the team can deliver per unit of calendar time. The points per sprint is the velocity. Therefore we estimate everything in points for the Product Owner so that he can create a release roadmap based on team velocity and adjust the plan if velocity changes.

The way we do story point estimation is better than hourly estimates as it is more accurate and has less variation. A CMMI Level 5 company determined that story point estimation cuts estimation time by 80%, allowing teams to do more estimation and tracking than a typical waterfall team. A telecom company noticed that estimated story points with Planning Poker was 48 times faster than waterfall estimation practices in the company and gave as good or better estimates.

Story points are therefore faster, better, and cheaper than hours, and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

(Editor’s note: This article originally appeared on Jeff Sutherland’s Scrum Log.)

Dr. Jeff Sutherland is the co-founder of the Scrum development process and a Senior Advisor to OpenView Venture Partners. He is a renowned trainer and speaker focused on helping businesses increase productivity through the power of Scrum. For more from Jeff, visit his Scrum Log blog site.

(Editor’s note: This article originally appeared on Jeff Sutherland’s Scrum Log.)