# Do story points have a direct relation with task estimates?

In my current team, where we run multiple scrums, the Story points are usually based on the effort required to complete the User Story. For example if an User Story has 2 tasks, both needing 5 days each, they the Story is assigned 10 points. So 1 day of effort is considered to be one Story point.

Is this practice a good one?

-

## 3 Answers

Sometimes it's useful for a team to start like that if they're having difficult grasping the abstraction. The most important thing is if it is working for you. However, that practice also has several limitations:

• Different team members will take different amounts of time on the same story. 10 points for the new hire should be equivalent to 10 points for the rock star, so you can dynamically reallocate stories as needed.
• Stakeholders will be tempted to rely on those estimates directly instead of velocity.
• Team members will be tempted to manipulate those estimates instead of thinking about it abstractly and letting velocity evolve naturally.
• It's difficult to factor in things like interruptions, availability, etc.
• Your resolution is fixed. Stories smaller than a day are likely to get overestimated.
• A lot of stories that involve debugging are difficult to estimate time-wise, but easier to estimate as a relative complexity.
• You will annoy agile purists (never mind, put that in the "plus" column).
-
Ha, you think day granularity is bad, I only use 1 day, 2 day, 1 week, 2 week increments (exponential scale)! I find people are more accurate at getting the right order of magnitude. –  Chris Pitman Aug 31 '12 at 5:18

Yes, it's fine. Story points are abstract units. They may be related or derived from real units, but it's not important what units, as long as all of the stories use the same units. Since the number of units of work allowed into an iteration is based on the number of units of work completed in the past, the units must be consistent.

Here's an example: Suppose that we tend to overestimate, on average, taking half the time to do a task as we estimated. In the last week-sized iteration we estimated 10 days worth of work but took five actual days to do them. Since past performance is 10 estimated days, we allow 10 estimated days into the next iteration. As long as our estimates are consistently bad, it all works out. That's why the actual units don't matter.

-

Yes, it is actually a commonly used practice, though some people would say you are estimating in Ideal Developer Days, or just Ideal Days. Don't get hung up on using the term story point. This method is actually mentioned in Mike Cohn's Agile Estimating and Planning book. See Chapter 5. Estimating in Ideal Days.

-