I had the good fortune to sit in on a day long session with Dave Hussman (who is awesome, by the way) on the topic Agile coaching as a lead in to the Atlanta APLN meeting. It was chock full of tips and I recommend getting out to see Dave if and when you get the chance; he packs a lot of knowledge into a short amount of time in an extremely entertaining way.

One of the questions he asked is: when is a feature done? This is a perennial topic with Agilists and it's a very valid question; how do we know when a feature is "potentially shippable?"

I piped up with my answer: a story is done when it's in production use. That was a little different than the answers from the others in the room.

Think about it: we're not delivering value until that value has been delivered. That's a very Yogi Berra way of saying that until the user's using, that feature you made isn't contributing to business value. In a way that's one of the original premises of Agile: release early, release often.

This is the reason why I like the cycle time measure over the velocity measure. Cycle time tells us how long the feature took from the time it was green lit to the time it went into production. This gives us a real measure of how long it takes to deliver business value. Velocity simply tells us how long a feature took to develop (unless, of course, we have release-per-iteration)

Agile asked us to work better as software development teams and deliver in tiny little batches. Lean asks us to do the same thing, but put the software team in the context of the larger organization and from the customer perspective. Think globally, act locally. Doesn't matter how rockin' a development team is, if those features are being held in inventory until waiting for some deployment event, they're not done; they're only done as far as you're concerned, and, last I checked, there were more than developers and testers involved in the process of delivering software.