How to User Story

User stories are extremely popular with agile teams and have become nearly synonymous with agile ways of working and Scrum, even though they are not part of the Scrum Framework. Unfortunately, when used incorrectly user stories are one of the worst ideas to come out of agile.

A recent conversation with a client revealed misuse of user stories that I don’t think is unique to that client.  The approach can be best demonstrated in the following illustration.

To me, this showed both a rigidity in using stories as well as that people didn’t really understand how to use stories effectively. And perhaps they were pining away for the days of old when we had those wonderful business requirements document where everything was spelled out in perfect detail. So we knew exactly who to blame if things went wrong.

It is not just that people think that they can use user stories as a substitute for traditional requirements documents. It is that the entire point of user stories was to foster conversation and create a shared understanding. The point was NOT to document in detail what the technology team needed to build.

The carryover from traditional requirements documents doesn’t end with the form. Some people carry on the tradition that we need a specialist to write effective user stories. So they call up the business analysts who were never really all that happy to be part of a cross-functional Scrum team anyway (See One More Time What is the BA role in Scrum?) and tell them to just write stories. They may even make up a new title – Story Writers. See if you can find that role in the Scrum Guide – you won’t.

The point is, some mistakenly think we need a specialist to go out and talk to business people, decipher what they need, and then write it down in a way a technical team can understand. This is not only an insult to the intelligence of most developers and QA professionals, it is pure waste.

Another common mistake is to interpret the form of the user story with the value. Most people today use the Connextra format for user stories. This is the old, AS A, I WANT, SO THAT format. It is not a bad starting point of course and I use it as training wheels for new teams. But there is no magic in the format. It is simply helpful to spell out the role, goal, and benefit. There are other ways to express it and some stories won’t fit that format and shouldn’t be forced.

Other teams re-introduce the requirements phase in agile in a more subtle way – through the use of spike stories. They create a “spike” for every story in the backlog and the spike is completed so that the story can be fleshed out and estimated. While this may be helpful occasionally, it shouldn’t be used just because you miss waterfall.

I could go on about user stories but perhaps it is better to just focus on how to use them properly, rather than rant about how people misuse them. As I was writing this blog, I realized that I already wrote a fairly good description of where user stories originated and how to use them properly in my 2015 book, Agile Project Management; A Nuts and Bolts Guide. So rather than reinvent the wheel, here is an excerpt from that book. And BTW, you can download this book for free – see details at the bottom of this post.

User Stories

Product backlog items are frequently stated as user stories, a concept that originated in Extreme Programming.  A user story is a way of expressing the business need in a particular fashion – to answer the questions of who, what, and why. Though many people use the concept of user stories, it is by no means required and it is not an official part of Scrum.

A handy way of thinking about the user story is the 3 C’s; card, conversation, and confirmation. In the early days of XP, stories were written on physical note cards, either 3×5 or 4×6.  The cards could be laid out on a table, they could be sorted and prioritized, and even be passed around and discussed in a meeting.  Notes were jotted on the cards during discussions to remind the team of specific details about the story.

One key benefit of the notecard approach was that teams were forced to make stories very small in order to be able to put them on a card.  It also prevented a lot of detail from being recorded since there just wasn’t much space for it.  Another benefit of the card approach was that it was low cost and lightweight.

The second C of the user story represented “conversation”.  With Agile in general and user stories in particular, the idea is to rely on discussions to get to a common understanding, and not on documentation. 

The card and user story were a reminder to have a conversation about the story. The Product Owner and team would meet and discuss the story; conversation largely replaced the detailed documents. Some teams may find it necessary to write something down, but many teams find documents unnecessary if they have small user stories and conversations with the Product Owner about the business need.

This is a big shift for many of us who have been involved with challenged or troubled projects and learned to document, document, and document some more.  We believed that good requirements documents protected us from scope creep and virtually guaranteed that we would deliver what the end users wanted.  Except that they didn’t!

The final C represents confirmation.  Confirmation means the test or acceptance criteria that will be used to determine whether we achieved the story or not.  By beginning with the end in mind, we make sure we all agree on what we are going to build.  Traditionally the acceptance criteria were written on the backside of the physical card.

The particular convention of the user story can vary. The format shown on the card above, “as a”…“I want”…“so that” was said to be developed at Connextra; it has been made popular by Mike Cohn and other Agile proponents.  An alternative format recommended by Craig Larman is shown in the card above.  Larman contends that this format helps facilitate better conversations.

Now that you understand the historical context for the user story, can you let go of the prescriptiveness and rigidity of user stories? Can you appreciate the simplicity and elegance of using story cards, as they did in the early days of XP?

Like this User Story Guide? Check out our other blogs that have similar free downloads: