RIP As a... I want... So that...
If you're more interested in the results than the conversation, skip to the summary.

Recently, I've realised that a lot of BDD has been very dev-focused. There's a reason for that. Dan's a dev, I'm a dev and most of the people who helped to evolve BDD are devs.

BDD's about the interaction between the business and the technical people in software. I want to know how it's working from the other side. So, I've been learning more about the customers, and particularly, more about BAs and their role. I had the recent fortune to run into Angela Martin at Agile India, where she taught me the art of grouping stories into coherent releases, while still keeping the stories granular enough that progress can be measured and delivery made regular and predictable.

Last night at XtC I met up with Chris Matts (of Real Options fame) who told me we're doing it all wrong. "It's not an art, it's a process," he said. "You're focused on the stories; that's why you think it's an art form. The focus should be the value you're releasing."

"Right", I say. "So, when we originally planned the stories that would deliver the value, we knew what would contribute to that value. But we've lost sight of that. Changes have been made. As devs, all we have are those narratives - the 'As a <role>, I want <a feature>, so that <some benefit is achieved>'. So we need to work out which of the benefits add up to the value we're aiming for. That helps us work out which stories we should try to complete for a release. The QAs are helping us work out what's ready; the BAs are helping us work out what's important."

"That's the problem," says Chris. "You're putting the role first. It's the value that's most important. Try this: In order to <deliver some value>, as a <role>, I want <some feature>. Instead of working out why people want a feature, and whether it contributes to the value, now we're working out who needs a feature, then assigning the story. So our stories are much more focused. If all the stories that contribute to a value are ready, we release."

I guess if we get to the point where we can release with only some of the stories ready, we didn't break down our values into granular enough elements. And when we want to work out what goes in a release, it's easy. The word 'release' is more meaningful. There's some untapped money out there - some market share, some cost saving, some battle against a competitor. All the features we produce go towards releasing that value for our customers to use - and it's the value we're releasing, not the features.

Thanks, Chris, for that.

I need to also thank Dave for giving me a better understanding of what a value is.

In summary: my preferred narrative now reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Because, in order for my work to have any meaning, as a dev, I want to know why you want it.

Edit: Chris said he posted this to the Kanban group on Yahoo, but they aren't responsible for it. Sorry, Chris, didn't mean to misaappropriate! See you on there soon.