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.

This entry was posted in stories and tagged , . Bookmark the permalink.

7 Responses to RIP As a… I want… So that…

  1. anonymous says:

    Thanks for a great writeup, Liz. Chris was babbling about this when I last met him at QCon. I’ve been thinking a lot about it since, and it’s beginning to stick with me. I’ll try this out pretty soon…

  2. ext_43883 says:

    That should teach me to use my openid more…

  3. anonymous says:

    I love this, but I think it will be hard to gain traction with it. After all, the “so that’s” are always the hardest thing to write in a story and are the first thing to be omitted, especially when working at the level of small, discrete functionality.

  4. sirenian says:

    Yes, the so-thats are the hardest thing to write in a story… but if you haven’t got a reason for wanting the story, why are you working on it? ๐Ÿ™‚

  5. anonymous says:

    Hi Liz,

    You’ve gone and done it now. ๐Ÿ˜‰

    One small correction, Unfortante to say that its my work rather than the Kanban group. Do not want to get them in trouble with the User Story zealots.

    Thank you.


  6. anonymous says:

    This is brilliant! Such a small change can make a huge difference. I was thinking, why not go more this way and just say:

    In order to [achieve some value], [role] can|will|must [do something].


  7. ext_101242 says:

    Another one learning to use open id…

Comments are closed.