What I do not believe is that you should not be using your early velocity metrics as proof of productivity gains to justify your agile adoption.

You will introduce all kinds of disfunction into your team if you encourage management to think of points as some literal measure of value.

Again, in an entirely agile organization where management “gets it” this is not an issue. But this is not the environment where one has to justify agile adoption in the first place.

Here are some concerns I have:

1) Stories vary greatly both in their size and their perceived value to the customer.

2) I’ve talked to Jeff Patton about whether it’s meaningful to try to monetize something as small as a story. He and I both are skeptical. So the idea that a story is a better actual measure of value delivered than points or simple burn is debatable.

3) Quality of story writing improves drastically as product teams become more adept at agile and so you have another pseudo quantitative metric that does not mean the same thing over time.

3) There is no baseline to demonstrate a before and after. Before agile there were no stories to compare against.

4) This may be a dangerous metric to put in place if you actually tie it to rewards and a team’s ability to continue doing agile. Stories gameable. The team might be incentivize to break a feature into as many stories as possible and customers to roll up features into as few stories as possible. Shared investment in stories is difficult enough to achieve.

5) The point of the post is using metrics to champion an adoption. For management to buy into stories as a meaningful metric and not distort what that means the same way people distort velocity would require a pretty sophisticated grasp of both what stories are and what agile/lean management entails.

The long and short is that I don’t think this addresses many of my concerns for using any metric for productivity as a case for adopting agile.

I would be willing to try it in a healthy agile/lean organization as input into portfolio management. I wouldn’t have tried it four years ago when I was talking people into letting my team introduce Scrum/XP.

Why not measure throughput? If your job is to deliver software then measuring the rate at which you deliver features seems like the right thing to do. If you are already using an agile technique the calculation is simple. Number of stories delivered to your customer per month.

See also
http://en.wikipedia.org/wiki/Throughput_accounting