First of all, it’s important to say that User Stories are not a part of Scrum as defined in the required practices in the Scrum Guide. User Stories are but one way to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. Still, though, I would like to remind you that the User Stories practice is totally independent of Scrum, and thus it is not defined by Scrum. As such, everything else in this post is about the User Story practice and not Scrum itself.

Beware the common misconception!

There is a common misconception in the industry that a User Story is a sentence like:
  • As a <user> I want <some functionality> so that <some benefit is realized>.
Whenever I give a presentation on User Stories, I will often put an example sentence like that up, and say, “What’s missing from this story?”

Let’s look at what a User Story is to get an answer to this question.

What is a User Story?

Mike Cohn, in his User Stories Applied book, defines a User Story as follows:
<snip>
A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects:
  • a written description of the story used for planning and as a reminder
  • conversations about the story that serve to flesh out the details of the story
  • tests that convey and document details and that can be used to determine when a story is complete
</snip>

In more recent writings, Cohn has referred more broadly to the last bullet as “Conditions of Satisfaction” (which still eventually turn into tests). Further, Cohn has expanded the “user or purchaser” terminology to mean any stakeholder of the system that is not a member of the development team. I’ll use the term “Non Development Team stakeholder” (or NDT stakeholder, for short) to convey this concept of a stakeholder outside the dev team.

Ron Jeffries, of XP fame, helped pioneer and create the concept of a User Story. He describes User Stories this way: “…User stories have three critical aspects. We can call these Card, Conversation, and Confirmation…” The “three C’s,” as he calls it, refers to the three bullets above in Cohn’s definition.

More Modern definition of User Story

So, now, our updated definition of a User Story is summarized as follows:

<New Definition>
A user story describes functionality of a system that will be valuable to a NDT stakeholder of a system or software. User stories are composed of three aspects:
  • a written description of the story used for planning and as a reminder
  • conversations about the story that serve to flesh out the details of the story
  • acceptance tests that convey and document details and that can be used to determine when a story is complete
</New Definition>

Conditions of Satisfaction

Some literature, in the context of User Stories, will use the terms ‘Conditions of Satisfaction’ and ‘Acceptance Tests’ interchangeably. At the basic User Story level, that’s true enough, but not exactly correct. The subtle distinction is an advanced topic, so the distinction is not important enough for this article. If you’re just getting your hands around User Story basics, then just assume they’re synonymous for now.

What do they mean by Acceptance Tests?

Typically, in the context of a User Story definition, we mean tests that are represented by conversations, textual descriptions, tables, diagrams, automated tests, and so forth. When these Acceptance Tests are applied to the completed, implemented User Story, all of the tests should pass, and will thus prove that the story has been implemented correctly. If some functionality was not covered in a User Story acceptance test, then it wasn’t a requirement for that particular User Story.

Technically, in the context of a User Story definition, an acceptance test need not be automated or implemented. At the minimum, it should be described conceptually. The test should then be executed in order to prove the story and get acceptance, whether that be a manual or automated process. If your conceptual acceptance tests are described by one or more automated tests, then that is generally a much better practice, but not absolutely required.

Acceptance Tests should be automatable about 90+% of the time, though again, it is not required that they be automated. Having said all of that, when teams strive for development speed and quality, very few get far along that road without automating a large portion of their acceptance tests.

Back to our original question…

Above, I asked a question about this so called ‘Story’:
  • As a <user> I want <some functionality> so that <some benefit is realized>.
Whenever I give a presentation on User Stories, I will often put an example sentence like that up, and say, ‘What’s missing from this story?’

The Answer: Hopefully, from reading this article, you can see that the sentence above is a description of a User Story, and nothing more. It’s missing the conversation, and the acceptance tests.

In fact, I think that focusing too much on the ‘As a user…” template is a User Story Trap. See the links below for more info on that subject.

Should I use a User Story to represent bugs/defects in a system?
This is a complicated subject, so see my other article: Should I Assign Story Points to Bugs?

Where do I get more info?
User Story Traps ,