As I learn more about stories and how they get written, I occasionally come across odd things that don’t make sense.

One of these is the technical story. Here’s an example:

As a developer,
I want an automated build
So that I can be sure my code works.

Of course, we’re resistant to letting developers have their own stories. So sometimes, instead, the technical story becomes:

As a business user,
I want developers to have an automated build
So that they can be sure their code works.

This doesn’t make sense to me either. Surely “working code” is part of another story, for any part of that story? Of course, the QAs are busy checking that code works! So why do we even need a build?

If there’s no benefit to the business, the chances are that a technical story isn’t really appropriate.

As a business user
I want the developers to refactor the UglyClass
So that... um...

Maybe not. In this situation, refactoring of UglyClass should happen when it enables some other piece of functionality to be delivered.

Feature injection helps us talk about the business benefit

There are some technical stories, though, which really do deliver something the business care about. You can find this out by asking, “Who cares if I don’t do this? Who cares if I don’t have an automated build? If I don’t write unit tests? If I don’t write acceptance tests?”

This is where the feature injection comes in. I’m flexing Chris Matts’s template a bit to do this; here’s how mine reads:

In order to <deliver some business benefit>
<these people>
will need <these features>.

Now we can start working out why it is that we write the automated build.

In order to minimize support costs due to poor code quality
The development team will need
To write scenarios and automate them.

In order to stop wasting money coding things that don't work in production
The development team will need
Automatic integration with a production-like environment.

In order to minimize the risk of our production environment falling over
The development team will need
Automated performance testing.

Users aren’t stakeholders

Interestingly, the people who care most about these things aren’t always the development team! The maintenance team care about support costs. The business stakeholders care about wasting money on code that doesn’t work. They also care about the production environment falling over.

We sometimes see this in normal stories too: that the user isn’t always the person who cares about the story.

As a user
I want to fill in a captcha box
so that... what? No! What a waste of my time!

Using “In order to…” we can turn this around:

In order to stop bots from spamming the site
Users will need
to fill in a captcha box.

Now it might be obvious that the beneficiary of this story is the person who has to moderate the site, or the commercial team whose adverts would become worthless in a morass of spam. But just in case it isn’t, we can capture both the stakeholder and the user:

In order to <deliver some business benefit>
As a <role> I want <some other role>
to <do something, or use or be restricted by some feature>.

In order to stop bots from spamming the site
As a member of the commercial team, I want users
to fill in a captcha box.

Feature injection helps us remove the implementation detail

So, going back to our technical stories:

In order to stop wasting money on code that doesn't work in production
As the budget owner, I want the development team
to integrate their code regularly with a production-like environment.

You might notice that when we word technical stories this way, the implementation detail – how the development team integrate their code – tends to fall away. All that’s important is that we do it; if automating that is the easiest way then we’ll do it that way.

(Interestingly, JBehave2 was developed with no automated builds. Running them manually was enough.)

Now we can talk about the business benefit of our stories

We can also see that there are three different things we can do with our new build, for three different stakeholders. Because we’re splitting up our technical stories appropriately, we can ask each of the stakeholders to help prioritise the stories, and to give us clear acceptance criteria.

In order to minimize the risk of our production environment falling over
As the person in charge of advertising revenue, I want the development team
to be able to verify the performance figures.

Now you know who you need in the story workshop, too.

“So, I want 90% of pages to load within 1 second, and it should be able to cope with the Christmas sales.”

Of course, the language still isn’t quite perfect, so you can now have the conversations about the real business benefit (maximising advertising revenue and user experience, minimizing the risk of the brand being stigmatized by an embarrassing failure) and splitting up the stories (situation normal vs. peak time).

“But, you know what? We’re not going to be able to do this until after we’ve finished the first internal release and have some idea of what the real content’s going to look like and which agencies we’re going to use for the adverts. Can we delay it till then?”

No problem. Let’s work on that first release.

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.