The Anatomy of a User Story

User stories are an enigma. While quite possibly the simplest way to identify the work to be done by an agile team, they remain, after 25 years, misunderstood and misused. In this blog post, I want to break user stories down to the basics and make it so that you can benefit from user stories as you should.

Simplicity

User stories should be simple, concise statements of problems to be solved. They are not requirements documents, nor are they design docs -- they are not documents at all. Or, as Ron Jefferies put it, "a user story is meant to be a placeholder for a conversation about the work to be done." Ron succinctly described user stories in terms of the 3Cs - card, conversation, confirmation. "Card" is a reminder to keep your stories short. "Conversation" is a reminder that the story doesn't transmit everything in the context; most of the understanding of a user story comes from conversations between stakeholders and scrum teams. Finally, "confirmation" is a reminder that user stories should give you insight into what should be true when the problem the story describes is solved.

Rachel Davies made this really easy in her now famous "As a <role>, I want <action>, so that <value or justification>" template from 2002. In Rachel's format for a user story, "confirmation" is contained in the "so that" clause.

Structure

It's important to understand that while Rachel Davies' story format is best practice, it isn't the ONLY practice. Write user stories any way that you like. Rachel's approach is simply one of the best ways. So, in short, there is NO REQUIRED STRUCTURE for a user story. What's important is that you capture the following:

• Who is the user? (Stakeholder, persona, role)
• What do they want to do? (Action)
• Why do they want to do it? (Value or Justification)

Anything else is simply fluff and can be left out. Add additional thoughts to notes about the backlog item; attach documents and drawings as you learn more, but the basic user story should be straightforward.

Now that we've discussed the basics of user stories, let's move on to how to write effective user stories.

It's About the Problem, Not the Solution

The biggest mistake I see with how people write user stories is writing them as requirements. In other words, the following might look like a good user story:

"As a college registrar, I want to be able to search for a student when a family member calls."

But does this make much sense? For example, what if the original conversation with the registrar sounded more like this:

"As a college registrar, I want to be able to connect a family member and a student quickly in the event of an emergency so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone."

It's been my experience over the years that stakeholders are REALLY GOOD at identifying their problems but are REALLY BAD at knowing the right solution (even when they think they know the right solution already).

Include Performance Expectations

Keep your user stories simple, but don’t shy away from simple extensions to the fundamental structure to include additional useful information. For example, what if the registrar from the previous example said they needed to make the connection within two minutes (as, according to their experience, callers in an emergency tend to get abusive after two minutes)? So, why not add that to the user story?

"As a college registrar, I want to be able to connect a family member and a student quickly in the event of an emergency within two minutes so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone."

See how easy that was? We added a simple performance expectation to the user story. The developers will know that part of the story is about speed and performance. They can factor that into their development plans.

What if the Stakeholder is Already Doing Something Less Effective?

Sometimes user stories are problems that need better, alternative solutions. The customer is already doing something but is having trouble getting the job done. You need the developers to understand what the stakeholder wants to STOP and the problem that needs solving. Extend the user story structure:

"As a college registrar, instead of having to make a bunch of separate phone calls trying to track down the student, I want to be able to connect a family member and a student quickly in the event of an emergency within two minutes so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone."

A Complete Template

In my online training program, Amazing Stories!, I provide the following template. 

AS A {user|persona|system},

[INSTEAD OF {current condition}]

I WANT TO {action} [IN {mode} TIME | IN {differentiating performance units} TO {utility performance units}

[SO THAT {value or justification}]

[NO LATER THAN {best by date}]

Please try using this template the next time you’re creating user stories. 

–

Want to stay informed on the latest scrum and agile stories? Please subscribe to stay updated. Explore Scrum Alliance certifications to discover a path that may be right for your goals.