Estimation Techniques: Story Points and Effort Hours

Estimation is one of those things within the Agile community that draws a lot of debate. This debate usually centers around the question of how to estimate. Should the team estimate in the relative concept of story points or in the absolute concept of hours or days? First, let's look at what the difference in between the two sides.

Story Points

As I mentioned earlier, story points is a relative sizing concept. In other words, it asks the question "How difficult or complex is this backlog item when compared to that backlog item?" 

To begin your relative estimation in story points, the team should simply look through your backlog and find the very simplest backlog item...the item that they can knock out with their eyes closed all day, every day with no problem. That backlog item is a "1" in story point estimation. That's your baseline.

Now, the next time you pull up a backlog item for estimation, think of it in relative terms to that baseline item. Is it about twice as hard as that super simple task? If so, call it 2 story points. The concept is that simple. You can do this type of estimation using story points, t-shirt sizes or any number of other techniques. The main idea is that backlog items are estimated relative to other backlog items.

Effort Hours

First, I want to direct you to check out Mike Cohn's book Agile Estimating and Planning for a great breakdown of Ideal vs. Elapsed hours. In Chapter 5, he writes about estimating in hours and gives a great perspective.

Basically, when you estimate backlog items in hours, you're making some assumptions. First, you're assuming that all of your time is spent on only this backlog item with no interruptions or distractions. You're assuming that no unknowns pop up unexpectedly. You're assuming that the backlog item would take the same number of hours, no matter which member of the team picks up the backlog item to work. These are some fairly dangerous assumptions and I would recommend staying far away from estimating backlog items in hours for these reasons.

I have a really hard time ever promoting the use of hours for estimation purposes, but Mike Cohn has, thankfully, already written a great blog post about why he doesn't recommend story points for sprint planning, so instead of trying to present both sides of the argument here, I will simply direct you to his post. If I tried to write about how hours are great estimation and planning tools, it would simply be a half-hearted and forced attempt to share an ideal that I don't believe in and that's not fair to you, dear reader.

Final Thoughts

You might have noticed throughout this post how I feel about the "right way" to estimate. This idea of a "right way" is just as subjective as the estimation process itself, so I urge you to read up on both sides of the debate and make the decision that is best for your own team's dynamics. As with all of Agile, what works best for one team may not necessarily work best for all teams and should be approached with an experimental mindset. Try doing it one way and see if it works for your team. If it does, awesome! If it doesn't, tweak your process or try another way altogether. Repeat until satisfied.