| That's just story points with extra steps. You're already using an abstracted measure of time, by working with a derivative value of "developer estimated hours". You're already doing timeline projections on the average throughput of your "adjusted developer hours" unit. That's most of the value right there. You can get even better results, with a little less cognitive load, by applying the research that people are much more consistent in estimating complexity than time (note that your method relies on consistency, not accuracy, to succeed). A quick imagination exercise validates this point for most of us: You bought a new IKEA sofa - how much time will it take to build? Honestly hard to do, and we're never accurate. But consider instead: how hard is it? Way easier to answer. And if you already know how long it takes you on average to finish other tasks of similar apparent difficulty... Try using your exact same system, but ask people to estimate the task in terms of complexity. Use any scale you like, as long as the units have consistent value in your developers' minds (I like "cups of coffee", personally). Make your Dev team agree on the difficulty score for each Feature, to ensure that consistency. Side benefit: Devs stop worrying about time and taking shortcuts (aka "technical debt") to meet their time estimate that you don't believe anyway. They're also a lot more likely to consider hidden risks and sources of extra complexity in the estimate. Then you just track the actual throughput with a confidence interval, and use that to make timeline projections with a confidence interval based on that tracking. TLDR: try asking Devs to estimate complexity rather than time, and use a moving average with confidence interval rather than the static 1.6 multiplier to make timeline projections. You'll find your projections more accurate and developers less stressed about it. You'll also have reinvented story points. |
There's no shortcut to avoid the requirement to present different summary statistics to different stakeholders. It's a consequence of decision theory. Unless they're equipped to understand the whole distribution.
It's also the wrong sort of rounding. I think an ikea sofa might take an hour, but if it took all day I'd be pretty shocked. But with software tasks, it's important to accept that the distribution is long-tailed. Sometimes it really will take 10x as long as you expected, and that's not your fault. Story points would have to abandon all meaning to capture that much variance.
I don't recommend incentivizing estimates, though. A big benefit of recognizing a developer estimate as short-hand for the median of a distribution is that when the time doesn't match the estimate, it doesn't mean the estimate was "wrong" or "bad", and the developer shouldn't feel bad.