The User Story: Demystified

What is a User Story?

Once upon a time, a software developer who was sick and tired of reading Use Cases, Business Requirements Documents, Technical Requirements Documents, UML diagrams, Interface Design Documents, decided to try a radical idea:

To an end user:
“Tell me a story. (I’ll write it down.)”
— Alistair Cockburn, wiki.c2.com

But, But…That’s Not What I Was Taught!?

I know, I know. You may have been taught that a User Story conforms to this format:

How did that happen?

That was a mistake of history.

Okay, so the idea isn’t quite as simple as annotating the stories end users tell us. Kent Beck, who is likely to have coined the term, asserted there is a difference between a “story” and a capital-S “Story”. Kent explained that:

A capital-S Story is:

• Testable: you can write automatic tests to detect the presence of the story.
• Progress: The customers side of the team is willing to accept the story as a sign of progress toward their larger goal.
• Bite-sized: The story should be completable within the iteration.
• Estimable: The technical side of the team must be able to guess how much of the team's time the story will require to get working.

— Kent Beck, wiki.c2.com

And given that seed, history shows that the concept grew and evolved. Many others attached their own opinions, patterns, and advice. Then books and blogs, tips and tutorials followed. Some were useful — many were not. Among the best known but most regrettable mutations of the concept of the User Story occurred circa 2001 when a development team at a company called Connextra established a format for notating their user’s stories.

“Best Known…”, I Said

The format Connextra’s team shared with the world became well known.

In the spirit of the Manifesto for Agile Software Development (e.g., “we are uncovering better ways…by doing it and helping others to do it.”), members of that team, such as Tim Mackinnon (sorry, Tim, I don’t mean to single you out), went on to be Agile Coaches, authors, and team leaders. And they shared their wisdom widely.

The format was, I believe, very helpful to them and I’m grateful they experimented with the format and shared it with others. I’ve personally learned a lot from their work and I’ve incorporated many of their ideas in my own practice.

“Most Regrettable…”, I Said

What began as one working agreement in one team in one company, became dogma for generations of developers, business analysts, and product managers.

The Connextra format is easy to describe, easy to teach, easy to copy — too easy. And just as I can warm a pre-cooked Beef Wellington in a microwave without learning anything about protein, pâté, or pastry, anyone can write the Connextra format without learning anything about user-centric iterative & incremental development.

I’ve consulted with teams who diligently and reverently write all their “Stories” in Connextra’s format. Regrettably, they’ve been led to think it’s “best practice” or a rule of Scrum. It is neither of those. There are no rules around User Stories, except perhaps one: listen to your users and write down the words that come out of their face.

Tips for Writing User Stories

With respect to the User Story concept and among all the tips I’ve been given and all the techniques I’ve practiced, these are the most valuable:

• The 3 C’s, Ron Jeffries
• INVEST in Good Stories, Bill Wake