Story points and hours of effort in Scrum
The key difference between story points and hours of effort is that story points are designed to compare the relative effort between tasks, while hours of effort calculations aim to predict the exact amount of time a user story will take to complete.
Strict, time-based estimates don't align well with Agile. In fact, they often fail even in Waterfall projects where projects frequently go over time and budget, as we see in construction and engineering industries. However, in Agile, rigid time estimates are particularly problematic because they contradict the entire philosophy behind the approach.
The Agile Manifesto emphasizes the importance of responding to change over following a plan. But without a rigid plan, how can you provide accurate, time-based estimates? You can't -- and that's the point.
Instead, Agile practitioners use alternative methods to plan and track work, and story point estimation has emerged as the most popular approach.
Story point estimation
Story point analysis enables teams to compare the relative effort required to complete user stories or features. The least effort is typically assigned a number value of 1. A story that requires three times the effort gets a 3. In this system, a story with a value of 3 should require approximately three times the effort of a 1.
To further improve the estimation process, Agile teams often rely on the Fibonacci sequence to assign points:
1, 2, 3, 5, 8, 13, 21
Alternatively, some teams use a doubling scale:
1, 2, 4, 8, 16, 32
The nonlinear growth of these sequences reflects the fact that larger stories carry greater uncertainty. The bigger a user story, the harder it is to estimate accurately -- and attempting to do so with precision is often unrealistic.
Bridging the gap between story points and hours
As you can see, there is a significant difference between estimating in hours versus story points. Agile teams prefer to avoid rigid deadlines, while managers and stakeholders often seek exact dates.
Fortunately, there is a way to bridge that gap.
When developers assign story points, they typically follow a general mapping, such as the following:
- 1 story point ≈ 1 hour
- 2 story points ≈ 4 hours
- 3 story points ≈ 1 day
- 5 story points ≈ 1.5 days
- 8 story points ≈ 2 days
- 13 story points ≈ 4 days
- 21 story points ≈ more than a week
With this rough mapping, managers can estimate how long it would take a team to complete 1,000 story points. This provides a loose time frame and maintains flexibility.
Story points and velocity
Over time, if a team consistently estimates and tracks story point completion, a pattern will emerge that shows how many story points they typically deliver in a sprint. This rate of delivery is called velocity.
Additionally, one can divide the number of story points completed by the number of hours worked to calculate a ratio of story points to hours. Some managers use this to further refine their estimates.
However, Scrum masters and Agile practitioners often view these velocity calculations with skepticism. Story points are inherently subjective and can be easily manipulated. For example, developers might overestimate points to inflate their velocity. Moreover, the same task might be assigned very different point values depending on the team's experience level. Senior developers might assign fewer points to a task than junior developers would, which skews the data.
| Story point value | Effort level | Time commitment level | Difficulty level | Risk and uncertainty level |
| 1 |
Minimal |
Less than an hour |
Minimal |
None |
| 2 |
Low |
One hour |
Low |
Minimal |
| 3 |
Medium |
Several hours |
Medium |
Moderate |
| 5 |
Medium |
One day |
Medium |
Moderate |
| 8 |
Significant |
One to two days |
High |
High |
| 13 |
Severe |
One week |
High |
High |
| 21 |
Maximum |
Two to four weeks |
Very high |
Very high |
Balancing competing interests
In the world of product development, there are always competing interests. Stakeholders want exact deadlines, but for Agile practitioners changing requirements make it nearly impossible to commit to specific dates.
To strike a balance, teams can use trends such as velocity and story points per hour to make rough estimates for timelines. However, this approach will never be perfect. In an Agile environment, mapping hours to story points is always a best guess, not a guarantee.
Darcy DeClute is a technical trainer and Agile coach who helps organizations apply Scrum-based principles to adopt a modern DevOps stack. She is a certified Professional Scrum Master, Professional Scrum Developer and Professional Scrum Product Owner as well as author of Scrum Master Certification Guide.