[jbay808]

Unfortunately, that just masks the difficulty by using ambiguous terms that nobody knows if they agree on, and makes communication hard with 3rd party stakeholders who don't share your conventions. When marketing wants to know when something will be done, we can argue about whether dev-weeks or calendar dates are more appropriate, but I think I'd get told right off if I tried to tell them it would take a hundred "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.

[ohthehugemanate]

Sorry if I was unclear, when talking to management outside of the project, you express in terms of time/calendar dates. The arbitrary units are just a more accurate and less pressured way of getting to time values, than "developer estimated hours times a static multiplier."

[jbay808]

It's not a static multiplier; I thought I was clear that it's very much a context-sensitive multiplier, which depends on risk tolerance (which you get, straightforwardly, from how far you integrate the tail of the distribution).