Story Points Are Not Hours
The request is always reasonable when it arrives. The resource planning system takes hours, the finance team needs a cost, and somebody asks what a story point is worth in time. Four hours? Six? Give us a rate and we will do the rest.
The rate is easy to produce and it removes the thing the points were there for. A point is a relative size, and converting it into a duration turns it into something it was designed not to be.
What a point actually is
Two properties make relative sizing useful, and a conversion removes both of them.
The first is that it is relative. A point measures this piece of work against other pieces the team has done: bigger than that one, about the same as this one. People are reliably better at comparing two things than at estimating one in absolute terms, which is why relative sizing is quicker and why it holds up better across a year than hour estimates do. A point carries complexity, volume and uncertainty together in one number, and that folding-in is deliberate.
The second is that it belongs to the team. An hour estimate implies a person: four hours for whom, working on what else, with how much of the context already in their head? A point estimate leaves that unanswered, which is what lets a team size work before knowing who will pick it up. Section 2.3 of the PMBOK® Guide Eighth Edition treats adaptive forecasting measures as observations about how a team is actually performing, and an observation about a team stops being one the moment it is expressed in an individual's hours.
Three things a conversion destroys
It reintroduces the individual, and with them the question the points existed to avoid. A five-point item is not five points for the senior engineer and eight for the new starter. It is a five-point item. Six hours each is not.
It removes the uncertainty content. Points fold uncertainty into size, so a piece of work that is small but poorly understood gets sized up, honestly. Hours have no room for that, and a converted estimate presents a number with its uncertainty stripped out, which is the least useful version of it available.
It turns a planning aid into a target. Once a point is worth six hours, points become a measure of output, and a measure of output that somebody is watching will go up. Estimates inflate quietly: work that was a five last quarter is an eight now, nobody has lied, and the number has stopped carrying information. Cross-team comparison follows, which is worse, because two teams' point scales were never calibrated against each other and were never meant to be.
What to do when somebody needs a date
The pressure behind the request is legitimate, and the answer is to give the organisation what it actually needs rather than the conversion it asked for. Two things usually cover it.
For a delivery forecast, use throughput. Take the points the team completed in each of the last six or eight iterations, take the lowest and the highest, and divide the remaining work by each. That produces a range, which is what a forecast is, and it uses hours nowhere. A team with a hundred and twenty points left, completing between eighteen and twenty-six an iteration, finishes in five to seven iterations, and anybody can check the arithmetic.
For cost and resource planning, use a capacity model. The organisation wants to know what the team costs and how many people are in it, and both of those are knowable without reference to points. Eight people for six months costs what eight people for six months costs, whatever the points do.
One point, six hours, two quarters
A telecoms operator's network engineering group was asked to put its work into the corporate resource planning system, which took hours. After some discussion a rate was agreed: one point, six hours. It was a sensible average drawn from the previous two quarters, and nobody objected to it.
Within two quarters, three things had happened. Estimates for comparable work had risen by roughly a third, which nobody had decided to do and everybody had done, because an eight bought more room than a five. A director had started comparing the two delivery teams by points completed, and one of them had scaled its estimates in response. And a six-month forecast built on the rate came out about forty per cent short, because the rate averaged a period whose work had been unusually well understood.
The resolution separated the two audiences. The resource planning system was fed from a capacity model, which is what it had always needed: people, availability, cost. Delivery forecasts came from throughput ranges and proved more accurate than the converted figures had been. The points went back to being what they are, and the estimates came down again over about four months without anybody being told to bring them down.
For a PMP® candidate, the thing worth carrying is that an estimating unit encodes assumptions, and converting between units changes them silently. A team asked to express adaptive estimates in hours is facing a request that will produce a number and destroy its meaning, and a response that supplies the number without saying so has answered helpfully and badly. Ask what the requester actually needs, which is usually a date range or a cost and not a rate. Practising where a reasonable request carries an unreasonable consequence is one of the sharper exercises in a structured PMP exam preparation course.
When the conversion request arrives, ask one question before answering it: what will the number be used for? A cost model and a delivery forecast need different things and neither of them needs a rate. That conversation takes ten minutes and is far easier to have before a rate exists than afterwards, because a rate, once agreed, becomes the thing everybody plans with.
Interested in going further?
The request for a points-to-hours rate is reasonable, easy to satisfy and quietly expensive. Omega's PMP® Exam Preparation works through estimating situations where the helpful answer is the wrong one.
Adaptive forecasting measures and the rest of the schedule work are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A115: Agile Estimating vs Predictive Estimating
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A121: When a Schedule Baseline Needs to Change
A120: Schedule Compression: Fast Tracking vs Crashing
A117: Velocity: Useful Planning Aid or Dangerous Target?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
