Putting the story back into the User Story

Why are User Stories quickly becoming forms of agile documentation rather than opportunities to share a narrative?

Whilst storytelling is a fundamental way that humans have communicated since cavemen painted onto the wall of their caves, I don’t think we use it enough in our modern day professional lives, especially in the Scrum teams I coach.

I think the use of “User Stories” is what sticks out for me, as their benefits now seem to exist as a means of documentation rather than an opportunity to engage in storytelling. As such, agile training courses will generally describe how to “write” user stories rather than how to “tell” them.

This week I ran a short storytelling workshop session at the very popular Agile Coaching Exchange in London.

After my workshop ended this week, I got chatting to one attendee (my apologies, I didn’t establish her name) who worked in a User Experience (UX) team and was struggling with communicating requirements to an offshore development team in India (albeit via a separate product team in the UK). She really liked the idea of “storytelling” as a means to help the team in India understand the users better, and (hopefully) deliver a better product as a result.

We talked a lot about how she was using User Stories to define requirements, and she asked a great question based on what I just talked about in the workshop that night….

“Is the standard user story format becoming a cliché?”

The science of storytelling tells us that our brains will ignore clichés where a lack of storytelling exists. It’s the same reason we switch off when the big company CEO starts repeating the same old corporate buzzwords in their speeches.

At this point, I think back to where I first heard the use of the word “story” in an agile context. I was just starting on my first agile coaching gig in BT and I was told to buy this book…

And in that book, a “User Story” is defined as…

“A story represents a feature customers want in their software, a story they would like to be able to tell their friends about this great system they are using.” – Planning Extreme Programming (Beck, Fowler 2001)

Interestingly, this XP book doesn’t really give any definitive answer on what a User Story needs to looks like. It’s described as a couple of sentences, and a promise for a conversation with a customer, without any implementation details.

Over the years, it seems the words “User Story” have become synonymous with a particular format (As… I want… So that…) and, in my opinion, that’s not a very “story-like” format in itself.

As such, I have been playing around with some different formats that I like more. I went back to the original XP definition and tried to imagine a customer telling someone else about the product features they are using.

I think who said this is an important part of the story – but I am trying to imply that the NAME of that person is important when it comes to storytelling. [The example above suggests the development team will know who Doug is, via a persona or prior user knowledge).

By the way, I still think User Stories should be short enough to be written on index cards, and I would still expect acceptance criteria to be detailed on the back of each of these

I’d love to know what you think, drop me a tweet…