It's not fuzzy. It's unit-less. The number has no size or meaning outside the list of other sizes representing the work for that particular team for that particular sprint. It doesn't transport between teams, it doesn't mean the same thing from sprint to sprint, and it doesn't represent any qualities of the underlying system. You're asking for the definition of something that's just a relative number. It's like asking how long a piece of string is.

That sounds whacked, so let me try again.

What I'm doing when I take a list of future system behaviors and ask a team to relatively them is creating the parameters to a model that doesn't exist yet. The process of creating, revising, and implementing the model is what the team does each sprint. That's why initial estimates are so whacked (and they should be). Yes, for your particular team on your particular project maybe you get to the end and say "Hey, on average a story point amounted to 1.5 days" But I have no earthly idea why anybody would do that or care about that translation. It would a _very bad thing to do_. You only know the "answer" once you're done. And the answer is empirically determined by application of the model; it's not a guess.

Remember the old quadratic equation? ax^2+bx+c=0? Story points are like knowing "b". So how big is "b"? See? Makes no sense. It's just part of a parameter used to do other things. "Size" has no meaning here.

> It's not fuzzy. It's unit-less.

Except that somebody will come along and just use it as a proxy for some unit they care about. And that will probably be time. Tada! You're right back where you started.

Counting things out in magic beans doesn't make the problem go away. Humans are pretty good at this exchange-rate business.

You might as well estimate in domain-specific terms that you can later actually verify and calibrate. Such as SLOCs, function points, object points, modules + tests and so on.

Somebody might come along. And they might not. The point is you don't have to create an exchange rate. It's not needed. When people do that they do it because they don't know what the hell they're doing. As I said, if you don't know what the hell you're doing, don't use story points.

You might as well estimate in domain-specific terms

Actually no. You could use your astrology chart to estimate, but the purpose here is to get better and better as you go along. Remember that we re-estimate each sprint (or at least we should). So the point is the informal model of execution evolves over time. The old way was constructing this huge model and spending maybe 20 hours creating the perfect estimate, then executing. The new way is spending 2 hours each sprint over 10 sprints, increasing accuracy each time. You want a simple, less complex model that can be rapidly iterated. Lots of little bad guesses converging on an answer based on real-world execution data.

This is getting much longer than a HN thread. I would caution you that things like COCOMO exist as a way to mathematically model how time interacts with development. It's a model, not an explanation. Don't confuse tweaking numbers in a spreadsheet with controlling or changing execution. Various models have various uses. Technology development does not break down in a scientific management kind of way. Yes you can decompose technical problems into tiny pieces and solve them. But people working together are not robots, and their work cannot be broken down in the same fashion as a algorithm can. Wish I had time to go into this. Check out this blog entry. http://tiny-giant-books.com/blog/agile-backlogs-sigh/

Thanks for the chat!

You're welcome. I agree that it can't be done purely algorithmically and I have an umpteen-thousand word essay on why coming down the pipe one of these days. I seem to be getting nigh-Yeggesque these days.

> Except that somebody will come along and just use it as a proxy for some unit they care about. And that will probably be time. Tada! You're right back where you started.

That can happen. But it doesn't have to. You can get adept at giving people the raw data and then reminding them that any interpretation is their data.

But there's something subtler at work. If you have a new version of the product ready every week that stakeholders look at, and if you allow them to adjust the plan weekly, then they will start to change the plan. As they recognize the feedback-driven nature of things, they stop pretending that their math on points can predict anything. Instead they use the points to control outcomes. E.g., by cutting scope and fending off nice-to-haves to make the dates they want.