Mapping Story Points With Hours
Does it make sense or is it plain dumb?
Story points is a very popular agile technique with its own share of lovers and haters. One of the most common questions I often receive from new scrum masters is what is the magic formula for mapping story points to hours? The response varies from being amused at the endeavor to outright frustration and despair, and it depends on how my mood is that day.
Why bother when all you need is hours
If you want the estimate in hours, why bother using story points in the first place? The most likely reason is the team has recently moved over to an “agile” methodology, and the SM/team learned about it in their scrum class. As sexy as story points are and planning poker fun, management and clients expect them to tell how long it will take and how much it will cost? That requires an estimate of time and not an abstract number. Billing the client also requires time-based estimates, especially if the client must approve the estimates before starting the work.
If you are in such a precarious scenario, why bother yourself and have a facade. Go ahead, and use hours directly.
An alternative possibility
An alternative approach that works predominantly in a time and material commercial construct is creating a shared understanding between the client and team that uses relative estimation/story points to estimate user stories. The billing uses the actual hours consumed. However, it won’t work in a fixed-cost scenario where the client or supplier needs to know the dollar value upfront to manage the risk (or whatever other reasons they may have).
Magic Formulas
There are two patterns I have seen when people are putting in these intriguing formulas. One is a linear approach like 1 story point = 8 hours or some other magic number, and the other is more ingenious. They define a range like below:
Points = Hours1 = 1–43 = 5–85 = 9–168 = 17–2513 = 25+
Both are ugly, but if you have to choose, the range based on is the lesser evil in my view.
Standardize and Normalize
If we standardize story points to hours in such a manner, how do we take complexity, risk, and uncertainty into account?
When done right, a story point should define the difficulty level of a story in terms of four parameters:
- Effort
- Risk
- Complexity
- Uncertainty
These are inherently subjective to a particular context and a team configuration. So efforts at standardization or normalization are misleading and not very useful.
Throughput-based approaches
One approach I have found helpful is for teams to split stories so that they are more or less of equal size. This way, if you can handle ten roughly equal size stories in the sprint, it’s a much easier task to pick up stories for the sprint and measure the velocity without too much number crunching. Suppose a story is not the typical size; you split it. This approach helps us be more throughput-based than the sizing jugglery and aligns more with the noestimates approach.
The Scrum Guide view
The scrum guide does not recommend or mandate story points anyway, so don’t bother too much if you are struggling to do it. The recommendation in the guide is — The Developers who will be doing the work are responsible for the sizing. Developer involvement is crucial as it will help ensure that estimates are realistic and meaningful regardless of what you use — story points or hours.
Context rules
The whole idea of story points is to accelerate our estimation process by using relative estimations. It is much easier to say that an elephant is bigger than a gorilla than to measure both animals’ height or weight. Keeping estimations as approximations that consider all the aspects comprehensively accelerates the estimation process.
However, you might need a more exact measure of the height and size of the animals up front n case you need to ship them somewhere and arrange necessary transport and cages. Understanding your context is crucial rather than blindly taking a practice because some fancy consultant promotes it in a training course.
The Wrap
Story points and hours estimates are fundamentally different approaches, serving a particular purpose. Be wise and choose depending on your context. However, if you see yourself doing these magic conversions — be wary. Stay Lean.
*** Did you like this? Feel free to bang that clap button. Do you want more? Follow me on Medium, LinkedIn or Instagram or read more here. ***
