How to User Story

User stories are extremely popular with agile teams and have become nearly synonymous with agile ways of working. This article explains why user stories are so powerful with agile teams and how to use them effectively.

User stories are ubiquitous in usage today. 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.

Interestingly, user stories originated in Extreme Programming (XP) where they were simply called “stories”. It was a technique that evolved to encourage conversations about needs. These agile stories from XP have evolved into user stories. Though not formally part of the Scrum Framework, most Scrum teams take advantage of them.

Benefits of User Stories

One of the key strengths of user stories is that user stories are written from the perspective of the user. 

That makes them easier to understand. It also keeps them free from technical details and the solution. 

How to Use User Stories Effectively

Creating effective user stories is straightforward. Agile stories consists of three fundamental components:

1. Role: Specifies who the story is for.
2. Goal: What the user wants to achieve.
3. Benefit: The benefit or value the user hopes to gain.

You can also think of these three elements as WHO, WHAT and WHY.

They key is to write the user story as a user, or from the user perspective. 

 

Stories In Extreme Programming (XP)

As mentioned earlier, user stories originated in Extreme Programming. We can learn something from understanding how they were originally used. And that includes the 3 C’s – Card, Conversation and Confirmation. 

User Stories on Cards

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, taped on a wall, sorted and prioritized individually, 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.

Conversations about User Stories

The second C of the user story represented “conversation”.  The idea was 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. That conversation largely replaced the detailed documents which were used traditionally. That doesn’t mean there is no documentations. 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 underlying 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!

Confirmation in the form of Acceptance Criteria

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.

How Not to Use User Stories

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. They were simply replicating the flawed process they used with business requirements. They wanted to have everything was spelled out in perfect detail. 

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 exactly 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. They assign the job of writing user stories to a business analyst who is not truly part of the agile team. 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 form that goes, AS A, I WANT, SO THAT. 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.

These are some of the most common ways to misuse user stories.

Bottom Line on Using Stories Effectively

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?