Hi, Hugh. Interesting question.
> So, fer instance--the value of a user story. Some ways to think about it:
> 1. A story should deliver working, useful code. [...]
> 2. A story should deliver real customer value.[...]
> 3. [...] A story should reduce the risk of the project. [...]
> In the end though, I still feel that a "user story" pretty much has to define some part of the user experience. If that experience is delivered through code, fine--if not, also fine. It's still a story. But then how do we account for all these other tasks?
I encourage people not to account for all those other tasks.
My default position is that teams should only count things when they
deliver value to the people we're trying to serve. Occasionally it's
necessary to use some proximate measure for that, like when you have
iterations that deliver internally before release. But generally, we
should only count work that delivers value to our audience.
Regarding your three categories, I'd say the code is irrelevant; it's
the "working, useful" bit that matters. In which case, it sounds like
the same thing as #2. And you can unify the other two by treating them
as risk-adjusted value.
For example, if your project is worth $1m and has a 50% chance of
failure, the risk-adjusted value is $500k. A story that cuts the risk in
half shifts the project's risk-adjusted value from $500k to $750k,
making the story worth $250k.
So I think you're entirely on the right track, and all of those are
aspects of story value.