Scrum Masters: Story Points vs Hours for estimations

In our last article, we talked about the goals of estimations. This article will enter into the religious debate of whether to use Story Points or Hours to estimate work within Scrum.
If these estimation metrics are new to you, here’s the quick overview. Hours are what most people use when estimating the duration of tasks. “It takes me 15 minutes to drive to work” or “I can paint that wall in about two hours”. Usually in Scrum, people estimate work in Hours, and it’s the time it takes a discrete piece of work to move through all the In Progress states until it is completed. Story Points have no basis in time and are a made up metric. They are only relative to each other, and each team’s points have different value from every other team’s points. One technique for assigning story points is to look at all the work you have in your backlog, find the smallest, and call it a “1”. If something is about 3 times that amount of work, it would be a “3”. Common values for Story Points follow the fibonacci number sequence, doubles of the previous number, or any number of numbering schemes to limit the numbers available for estimation.
So which is the best metric, Story Points or Hours? Like all great debates, it depends. Some die-hard agilists will say that it’s impossible to know the hours assigned to a given task because you don’t know what you don’t know, so tying yourself to a real-world timeframe is setting yourself up for failure. Others will say that story points are too ambiguous and don’t allow for easy forecasting and planning. Telling a non-agile director that a given feature will be delivered in 3 weeks is easier than saying it will be delivered in 245 story points.
When it comes down to it, the two factors that should drive your choice in hours vs story points is how well do you know your work and how accepting is your organization of agile practices.
If you know the work that you are doing very well, you probably have a good idea as how long it will take you. It should be fine to do time-based estimates. If the work you are doing is repeatable, has known quantities, and not a lot of unknowns (think “production line”), then time is a fantastic metric. Some would question whether you are in an Agile environment at that point, but I think there is a lot more that goes into working with Agility than how you actually accomplish the individual tasks (that’s a post for a another time).
Story Points are designed to be ambiguous for times that your work is ambiguous. A lot of software development involves solving a problem, similar to completing a puzzle. You aren’t really sure how long it will take to figure out. That involves a lot of factors, such as how complex the problem is, how much effort goes into putting the pieces together, and what hidden dependencies exist that you failed to identify at the outset. Story Point estimation is simply relative. You compare two puzzles and say “This is one is bigger than that one, but smaller than this other one” or “These are roughly the same size.” You will probably see a lot of agile coaches pushing for Story Points to help acknowledge the fact that we don’t all that goes into some given work. Likewise, you may see a lot of development teams pushing for estimates in Hours because Story Points feel ambiguous and fuzzy, which is uncomfortable in a world were concrete answers and solutions are prized. It’s important to understand both methods and let the team decide.
The second factor that should influence your team’s decision to adopt Story Points or Time-Based estimates is how accepting your organization is of agile practices. If you are early in your Agile adoption, you may still have a lot of people who want to know what will be delivered 6 months from now. By moving to Story Points, you throw a wrench in the gears of long-term estimates. You intentionally make it difficult to predict what will be delivered in the far-future. Agile is based on the concept that the ideal product emerges, and cannot be planned up-front. Story Points divorces the work from a real-world timeframe. It can still be tied back to real-world time using metrics such as velocity, but it forces everyone to acknowledge that there is ambiguity in the estimates. Velocity is a moving metric, and it will increase or decrease over time for a variety of reasons. The further out you use to forecast, the less reliable it becomes.
When work is estimated in time, a traditional organization will tend to see these estimates as commitments, not estimates. If you are early on in your adoption of Agile, you may want to consider Story Points for the simple reason that it reinforces the fact that we can’t know exactly how long each discrete unit of work will take, because we are solving puzzles, not painting fence posts.
