The user story is a product's foundation. It determines the design, the implementation, and ultimately what is tested. Get it wrong, and the entire project goes kaboom!
Unfortunately, many teams don't create good user stories. I’ve come to realise that the root of the problem is that most people misunderstand what a user story is. Notice that I said “most people,” not most product managers, because although product managers create the stories most times, the problem usually stems from the entire team’s misunderstanding of the concept. So this isn’t a piece chastising PMs, but more on that later.
First, let's clarify what a user story is.
Atlassian defines a user story as “an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.”
Notice that this definition says nothing about how the feature works. Yet, you've probably seen many user stories that include solution details.
E.g: ”Acceptance criteria: The user should see a button that can be clicked to go to the next page”
This practice tends to be more common in projects with less experienced developers or designers who often struggle to work without specific instructions, forcing the product manager to specify the “how” — the implementation of the solution.
While this approach might result in a working product, it risks building products that fail to address the user's actual needs. This, in effect, results in the project manager unknowingly sabotaging the team's testing efforts since tests are supposed to confirm that the product satisfies users’ needs, not just that it functions.
So, what user story mistakes should PMs watch out for, and how do they affect tests?
Over-specification in user stories can completely derail the product development team and lead to misaligned tests.
When product managers define exactly how a problem should be solved in the user story, they limit creativity and potential solutions, potentially jeopardizing the product's success. A user story defines the user's perspective on their problems and desired solutions, not dictate specific implementations.
Using our earlier example "The user should see a button that can be clicked to go to the next page". How does the PM know the users would prefer a button? What if a swipe presented a better user experience? Wouldn't the UX designer be in a better position to make that choice?
When user stories include implementation details, testers create tests based on these specifics rather than user needs, reducing them to merely verifying implementations instead of testing for user satisfaction. Misaligned tests create a false sense of a quality product and hinder the team from delivering truly valuable and user-centric solutions.
By focusing too much on implementation details, we risk building products that fail to address the user's actual needs, making software testing more difficult and less effective.
Lack of context in user stories, specifying who the user is or why they want the problem makes it tough for testers to figure out what’s most important to the user and hence makes test prioritization challenging.
It is impossible to test every aspect of a product in detail, making prioritization a necessity. So, testers must prioritize to continually release products without disrupting user experience. Without context, they are left in the dark about which aspects of the functionality are most critical to the user, making prioritization a guessing game.
"As a user, I want to be able to print my documents". This story has no context as to why the user wants to solve that problem or who the user is. However, "As a user who is always on the move, I want to be able to print my documents" provides more context on who the user is. Now the team can propose diverse solutions, e.g., making the printer portable so the user can use it anywhere. Testers can then test the portability of the product and verify if it passes the acceptance criteria.
This lack of context in user stories also makes it difficult for testers to think like real users ****and conduct effective exploratory testing which would have helped identify bugs that weren't anticipated in predefined test scenarios.
leaving out the "why" in the user story, hinders the team's ability to make informed decisions about resource allocation and feature prioritization.
Using technical jargon in user stories creates communication gaps among stakeholders involved in product development and can seriously hinder effective testing.
When user stories contain technical terms that non-technical stakeholders can't understand, they create a barrier to effective communication. This can lead to ineffective or unnecessarily long meetings as team members pause to look up complex words or ask for clarification.
For instance, a user story that says, "As a user, I want to use OAuth 2.0 for authentication so that I can log in securely" is not overly specific, but it uses technical jargon, alienates non-technical team members who might not understand what OAuth 2.0 is. A good user story should make it easy for everyone to understand where the product is headed, creating a clear vision for the entire team.
But how does this affect testers? Aren’t they supposed to be technical? When testers encounter user stories filled with technical jargon, they might focus too much on testing specific technical implementations rather than overall user satisfaction. This can lead to a situation where the product works perfectly from a technical standpoint but fails to meet actual user needs. The use of jargon can also hinder meaningful contributions from non-technical team members, potentially missing out on valuable insights that could improve the product.
Every team member should understand the user story. When it's clouded by technical jargon, it affects the work of everyone on the team, including testers which can lead to misguided tests and inefficient resource allocation.
So how can you create user stories that lead to software products that users love?
Stick to these guidelines, and you'll create user stories that actually help your testers, not hinder them. They'll be able to validate the technical aspects of your product as well as user satisfaction, setting you up for a successful product.