Tuesday, 4 August 2015

As a Developer, I Want to Abolish User Stories, So That I Can Ship Great Products Faster.

Once upon a time, when you programmed by the seat of your pants and the handlebars of your moustache, lots of people wrote specifications. And there was this lovely idea that you could get a Business Analyst to write you a specification, which laid out in very precise detail exactly how The Software was going to function, and then you would give the specification to a development team and they would build it for you, and Everything Would Be Lovely. Except, of course, it wasn't. Only one team ever shipped a massively successful project using this sort of specification-driven waterfall approach, and trust me - they were smarter than you, and they had a much bigger budget. So some bright folks started wondering why software always went wrong, and suggested a whole load of things that would probably help, and came up with things like scrum, and unit testing, and continuous integration.

One of the great ideas that came out this movement was the idea of user stories. See, specifications tended to be incredibly dry and formal, and often did a really bad job of communicating exactly why you were doing something. Joel Spolsky wrote a great article years ago on writing painless functional specifications, but user stories takes this idea even further. And, like a lot of the good ideas that came out of agile, there's a descriptive element to it and a prescriptive element to it. The descriptive part says "write short, simple stories, not detailed specifications" - and the prescriptive part suggests some 'templates' to help you get the hang of this. There's two formats that became popular for working with user stories - given-when-then and as-a-I-want-so-that.

As-a-I-want-so-that is pretty good for describing, at a very high level, what you are trying to do:

As a marketing coordinator, I want to send email to everyone on our mailing list, so that I can tell them about our big summer sale.

And then you'll add a couple of acceptance criteria to the story:

Given I am not subscribed to the mailing list, when the marketing coordinator sends an email about the summer sale, then I should not receive the email.

Given I have received a newsletter email, when I click the unsubscribe link, then I should be removed from the mailing list.

This sort of clarity makes it easy to build the feature, easy to test the feature, and easy to understand exactly what you're doing and why. See? Simple.

Right. Imagine we have a spec from the Olden Days, and Volume 6, Section 8, Subsection 14, Paragraph 9 says:

The handset will feature a Maplin RK82D component installed on the side of the unit. The RK82D will be positioned exactly 45mm from the top of the unit. When activated, the RK82D component will cause the internal speaker to emit a square wave signal at 16Hz, at a volume of not less than 90dBA as measured from a distance of 1 metre.

Now, let's take an old-school project manager and turn them into an agile product owner. Probably by sending them on a three-day course with a certificate and everything.  When they get back, they'll dig out the old spec, and they'll laugh at how dry and opaque it all is. And they'll sit down, all excited, and start writing stories that look like this:

As a handset user, I want a Maplin N27QQ component installed on the side of the unit, so that when the component is activated the device will emit a square wave signal at 16Hz at a volume of not less than 90dBA measured from a distance of 1m

And then they'll add acceptance criteria:

Given I am a handset user, when I activate the N27QQ component, then the frequency of the square wave signal will be 16Hz

Given I am a handset user, when I activate the N27QQ component and measure the signal volume at a distance of 1m, then the volume of the square wave will be not less than 90dBA

Given I am a handset user, when I examine the handset, then the distance of the N27QQ component shall be 45mm from the top of the unit

and everything is AWESOME because we're being AGILE! The story will sit there in the icebox for a couple of weeks, until it gets bumped up the list and included in a backlog refinement meeting. At which point this conversation will happen:

Dev: "Er... why are we doing this? I don't understand the justification for including this feature."
PM: "Sorry, what?"
Dev: "Well... do you know what a Maplin N27QQ component is?"
PM: "It's the component specified in the specification"
Dev: "Yes... it's also a big round red plastic button the size of a softball"
PM: "Oh. Well, it's in the specification now."
Dev: "Right. Explain to me what happens when you press it"
PM: "Oh, easy. The unit emits a square wave signal at 16Hz, at a volume of..."
Dev: "Yeah, yeah. Do you know what that sounds like?"
PM: "Er... it's probably some sort of ring tone"
Dev: "No, it's a fart noise as loud as a motorcycle"
PM: "Oh. Well, can we estimate the story, please?"

At which point the developer will start flicking through LinkedIn on their phone and wondering how long it is until they can go to the pub.

You know what the story should have said? It should have said something like:

As Bongo the Clown, I want my new phone handset to feature a massive red fart button, so that I can make children laugh at parties when I answer it.

First of all, unless you happen to be in the circus supply business, someone's going to say "hang on - why are we making phone handsets for clowns? Is that a thing now?"

Second, anybody who reads that story can immediately picture what they're building, who wants it, and why. It leads to creative discussion and suggestions. Someone might have a brilliant idea about replacing the fart noise with a trombone, or making the button light up when you press it. One of your team might remember how Dad used to get mad every time Tony Blair came on the radio, but the volume knob on Dad's stereo fell off when he tried to turn the radio off, and how hilarious it was watching him chase it across the kitchen while cursing and muttering under his breath, and maybe we should make the fart button actually fall off when you press it so Bongo has to chase it around the room? Clear stories let you cut through the waffle and get straight to the important bit - what is this? How do we build it? How might we make it better?

Now, compare these two sentences:

  1. As a handset user, I want a Maplin N27QQ component installed on the side of the unit, so that when the component is activated the device will emit a square wave signal at 16Hz at a volume of not less than 90dBA measured from a distance of 1m
  2. We'll put a giant red fart button on the side of the phone, so that Bongo the Clown can use it to make kids laugh when he's doing children's parties.

Which one makes more sense to you, as a reader? Which one is going to lead to better decisions, better estimation and less time wasted in meetings?

As-a-I-want-so-that is not some sort of witchcraft. It doesn't magically translate your dry, meaningless specification into readable English. Like writing unit tests, it can help to keep you honest when you're breaking bad habits, and it's one more tool to keep handy when you're doing this stuff for real, but it is not why we're here. It's the story that matters, not the syntax. And if you can't tell me a short, simple story about what you want and why, then maybe you don't actually understand the thing you're trying to build, and no amount of syntactic convention is going to fix that.


Nathan said...

Sounds like what you're really complaining about isn't user stories at all but project managers who aren't engaged when what you want is a product owner/champion who try to ensure that they are always pursuing what is best for the product in collaboration with the developers.

Whilst user stories aren't perfect and can go horribly wrong (you have some good examples of user stories gone wrong in the post) they are still a lot better than the old style requirement documents we used to have to deal with.

So perhaps the post title should be - As a Developer I want a product owner that is engaged with my product so they don't ask for stupid ass things which add no value to the product and should be droppped :-)

Ed Blackburn said...

Hear, hear!

My pet peeves are after the laborious time consuming and excrusiating story meeting. Evaluating stories against definition of done kills another few hours.

After, the story has to have acceptance criteria. Written in gherkin. Parsed to invoke an underlying testing library. That you may have wrote anyhow to unit test. Meaning in the time you've shoehorned all the process gates through the cookie cutter. You could have written, tested and delivered the story. Why do we do this? It's written on the wiki somewhere.

Keep it simple and focus on a low ceremony process. The purpose? Delivering value.

foobar said...

I think you are confusing specifications with requirements here. User stories are a way of expressing requirements, which in general should avoid any reference to the technical solution. In your example you were trying to take a specification and re-cast it as a requirement in the form of a user story and that doesn't really work.

Glenn Sills said...

When you are developing software for a company whose business is not selling software you run into three problems:

1. The business 'analysts' have little or no understanding of software and what it can do and very often few analytical skills. They are most either people in the business who have worked their way up to a higher paying 'analyst' job by being a hard worker, or a project manager by another name.

2. Software developers need to understand the business well enough to right envision the software for themselves.

3. Software developers don't want to study the business in order to envision the software themselves. It's boring.

4. The business doesn't want the software developers to have that much 'power' for a lot of reasons, including job security.

We are all doomed...