Suzy: Daddy, tell me a story.
Dad: Certainly sweetheart.
As a: Business person
I want: You to go to sleep
So that: I can go back to reading sales reports.
Suzy (Angrily): MOM, HE’S DOING IT AGAIN!
Have you ever noticed that articles about creating user stories never talk about the fact that it is called a story because it is supposed to tell a story? People know how to tell stories so why not let them?
Personally, I have found the “As a:, I want:, So that:” format to be restrictive. I have also found that it tends to stifles real communication (an Agile no-no).
If you think about it, software development is all about storytelling, with three basic types of stories:
What & When
How & When
The customer or end-user tells us What they want and by When they need to have it.
We, the technical folks; usually business analysts, architects and product owners, work with the requester to clarify the story of What and When.
We then start writing, first at a very general level, the story of How the request might be fulfilled and When this might happen.
The story of Why is a very important story that often gets overlooked. It should be more than just “so that I can do X, Y, Z”. In fact, the story of Why is the thing that allows us to be agile. It identifies what is really important to the user and thereby tells us where we can be adaptive if we need to be.
For instance; if the Why is to reduce cost, then perhaps the user interface design is less important. If the Why is to increase sales, then fully developed functionality may not be as important (a.k.a., Lean Development).
The story processing itself is that we continue to refine, clarify and breakdown the stories of What and How and When to the point where we have everything we need in order to go into production.
Think of it like writing a book, a novel. We start with the basic concept. We then do an outline followed by fleshing out the parts and sequence of the story.
Jumping now to the bottom of this particular metaphor; think of sentences as the thing the programmers create. At the beginning of the Sprint, no one knows what those sentences are going to be. Everyone does know what story the chapter needs to tell (the Sprint goal).
In the Sprint, the programmer writes the sentences which make up the paragraphs. Each paragraph tells its own little story which can be confirmed by the testers. The paragraphs are then combined in the proper sequence to create the chapter which is itself a self-contained story (a potentially shippable iteration).
Lastly, we put together the chapters to create the book that tells the story of our product and over time, the collection of books comes together to tell the story of Our Product Library.