Agile estimation – story points vs. hours

Once again, discussions at work have driven me to write this. This time, the topic of debate (or rather, amusement) is that in an agile team, hours (or days) and not story points are a better way to estimate user stories. I disagree.

Developers are, in general, more aware of the potential complexities that they can run into in the process of implementing a story. Despite this cognizance, it is often hard to predict exactly what these complexities might be. Obviously, if a developer knew the exact nature of the issues that he will run into, he can account for those and predict exactly how much time the work might take. Since this knowledge can never be complete, no developer can determine the exact amount of time needed.

Further, depending on the specific process being used in a given team, it is possible that the developer(s) who estimated a given story is not the one who ends up actually doing the implementation. Different developers have different skill levels and differing amounts of domain-knowledge. This also contributes to the variance in the actual time taken for implementation.

Finally, there are things that developers have no control over – the so called external factors – source-control going down or behaving erratically, having to attend meetings, or having to help another team or another developer on something, and so forth. Someone with critical knowledge could be out on vacation or a key developer could fall sick.

Lets represent actual time taken by a developer to complete a story with the following formula ->
A = function(C, U, E, S, K)
where
A = actual time
C = an idea of complexity (how difficult something is, and how many tasks there may be),
U = unpleasant technical surprises,
E = external factors,
S = implementing developer skill level,
K = available domain knowledge

Clearly, the only thing that can be “estimated” here is C – an idea of complexity (also based on the “understanding” of the team – whatever that is, and however it can be quantified). Let’s say that we measure this with complexity points (or story points). If we assume that everything else will get averaged out over the duration of the project (which it usually does), then it all comes together quite nicely. This is why story point estimation works.

On the other hand, trying to estimate using hours is like trying to guess the effect of the other four (and possibly more) factors. Trying to estimate in hours is like trying to estimate both the effort needed due to complexity AND the velocity of the people working on the story.

Finally, if I hear someone say that they have a capacity of 400 real hours, that they’re signing up for 600 hours of work and end up completing 500, then in my mind, the 500 hours of work that got done (which can’t be squeezed into 400 real hours) might as well be 500 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 400 real hours (time doesn’t change), they signed up for 6000 points and got 5000 done, it will not change a thing. Story points are story points. The team can call it “ideal hours” or “estimate hours” or whatever they like. As long as they’re not real hours, they’re just like a rose with another name…

About these ads

8 thoughts on “Agile estimation – story points vs. hours

  1. Very interesting post . This is the exactly same situation we are running into where team wants to do the estimate in hours as they feel this is what they can do best rather than estimating in story points which only factors the complexity & not the time(hrs). And from their point of view how they should determine the complexity itself is not very clear so they feel reluctant about the story point estimates.
    I must appreciate the formula that you have used to describe why use story points. Quite helpful.

    http://twitter.com/sonalibhasin

  2. Can you explain why this statement is true?

    “the only thing that can be “estimated” here is C”

    To me it seems it would be even easier to estimate S and K (developer skill and domain knowledge).

    I realize this does not change the wisdom of your post.

    RIELmanriquez.com

  3. It is amazing how this issue won’t die. Long thread on LinkedIn group arguing this very point. Prompting me to write a similar article with more detail on how to do story point estimates and iteration/release planning.

    I love the formula and may add that to the article. I will fully cite your article of course!

    Good work!

  4. Well , this is nice formula but still I don’t understand a situation where we ran into . For instance when you need to give estimation for your project which is proposal stage and needs funding from management , they typically ask for man hrs . How that is being translated to give a rough estimation ? For example I derive at 800 story points. Management can’t take decision based on that and I think this is something very debatable thing in agile. The only think I can imagine is to have educated guess on team’s velocity and translate into man hours and estimation might be larger considering other factors such as external event from above formula. Can anyone have better solution for this scenario.

    • So, after you calculate the estimates for the stories, you have to do a “Raw velocity exercise”, to find out how many points can be covered in one Iteration. After you get this number, you just divide the total points with the points per Iterations to find the number of Iterations you need.
      You can then easily convert this to Man Hours.

  5. Pingback: agile project management

  6. Ӏ feel that iss among the most vital info for me.
    And i’m glad reading your аrticle. But want to commentary on few normal things,
    The weƅ site taaste is perfect, the articles is really great
    : D. Jusst right jߋb, cheers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s