One of the developers asked me the other day why we used hours and story points and not one or other instead of both. I answered:
Picture a car on a cross-country trip.
Hours are like the car’s speedometer in that it shows how fast you’re travelling right now. It can indicate when you might reach the next city but not a city three states away, or on the other side of the country. Hours show you how fast you’re burning down remaining work in the current sprint.
Story Points are the odometer. On that same trip, it will give you an idea of how much ground you can cover in a week or a month. Traffic patterns, stops for gas and sleep are averaged out. Predictions can be made about when you’ll make it to the next state and eventually, the other side of the country. Story Points tell you how fast you’re burning down towards upcoming releases.
Both are needed because your odometer won’t stop you from getting a speeding ticket and your speedometer won’t let you know when to expect to stop for gas. Likewise, it will be hard to predict a release plan for the next couple of months based on the hours completed in a single day.
Lastly, the tachometer is our pace. We want to maintain sustainable pace without redlining. Too low and we burn up too much fuel for the distance covered. Too high and we burn out the engine.
Redlining might be harder to detect but consider how often people are working over time. Is it the exception or the rule? Is there a lot of churn in the backlog? Are there a lot of meetings cutting into the team’s time? Are sprint being cancelled when they go off the rails? On the flip side, is work done (Definition of Done) at the end of the sprint? Does the team miss a sprint once in a while? Is variance low (under 10%)? Are people bored? The team might not be pushing hard enough.