Liz Keogh's blog

Technical stories don’t make sense

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.