I take questions at the end of every Better User Stories webinar. I've done enough of these sessions that I can almost predict which user story questions are going to pop up in the chat!
I thought it might be helpful to answer three of the most commonly asked questions about user stories all in one place. Feel free to share it with your teams and stakeholders, to help get everyone on the same page about user stories.
Are User Stories the Same As Requirements?
Are user stories the same as requirements? Not quite, but they’re close.
Rather than thinking of a user story as a requirement, I find it more useful to think of each story as a pointer to a requirement.
Most commonly, every story is a placeholder for a future conversation between the team and its stakeholders. During that conversation, stakeholders will convey the details about what is needed. If more detail is needed than can be conveyed in a conversation, the story may point to a flow diagram, a sketch of the user interface, sample data, instructions on how to perform a calculation, or so on.
A user story itself is too vague to be considered a requirement. You’re better off thinking of a story as a pointer to a requirement.
Who Writes Acceptance Criteria for User Stories?
Who writes the acceptance criteria for a user story? Well, since the product owner is the one who will accept a story, or not, the product owner needs to be the one who writes the acceptance criteria (also known as conditions of satisfaction).
This does not mean that the product owner is forced to document a lengthy list of tests. The product owner documents only the acceptance criteria; those items so vital that the product owner will reject a product backlog item if it doesn’t fulfill the criteria.
Acceptance criteria are higher level than test cases. Think of the acceptance criteria as the table of contents into a test plan containing all the test cases.
As an example, a product owner might give as an acceptance criterion that the results of some search can be sorted by the user. It would be up to the rest of the team, very likely testers or QA, to turn this into specific tests, such as the following:
- The list is sorted by any column header the user clicks on
- The list is sorted in ascending order the first time a header is clicked on
- The list toggles between ascending and descending order with subsequent clicks
- And more
If the product owner would reject the item if any of these is left out, the product owner can include that in the acceptance criteria. The key is that acceptance criteria includes only things so important the product owner will reject the item if any is unmet.
Is a So That Clause Required on User Stories?
The most common way of writing user stories is with the familiar, “As a type of user, I want some goal so that some reason.” This template provides details about who wants something, what they want, and why they want it.
But is the why, included in a so-that clause, required when writing user stories?
Before I answer whether a so-that clause is required, I want to stress that I think it is often the most important part of a user story. Knowing why someone wants something can sometimes tell developers a better way to achieve a goal.
A couple of hours from now I’m flying from my home in Idaho to Denver. I don’t necessarily want to go to Denver on this trip. I want to go to southern California, which is my final destination. There’s a big difference between, “As a passenger, I want to fly to Denver” and “As a passenger, I want to fly to Denver so that I can get to southern California.
As another example, suppose you’re building a robot vacuum cleaner and someone gives you a story of “As a user, I want to train the robot to stay off my hardwood floors so the floors aren’t damaged.”
The so-that clause in this case suggests that users don’t really want to train the robot. They’d prefer it just somehow knew what to do. So a better solution would be for the robot vacuum to have a mode where it stays off all wood floors without training. A so-that clause helps by making the user’s goal more clear.
Is the so-that clause required? No, it's not. There are times when it doesn't add any new information to the story. Consider this user story: “As a member, I need to login.” Adding, “so that only I have access to my information” doesn’t add anything.
So, the so-that clause is not required, but you’ll benefit from always considering a so-that clause and writing one for the vast majority of your user stories.
User Story Help
User stories are a great way to ensure your product backlog is focused on customer needs, but that doesn't mean stories are easy to master. Check out the related resources or attend one of my periodic user story webinars to get more help with writing and splitting user stories. You can also sign up for weekly email tips, designed to give you little tweaks to improve team performance.
