Some product owners and teams are so fond of user stories that everything is expressed as a story. This either results in some rather odd stories – stories that capture the user interface design, complex user interactions, and technical requirements; or these aspects are simply overlooked.
Like any technique, user story writing has its strengths and limitations. I find stories particularly well suited to capture product functionality, and when applied properly, nonfunctional requirements. But user interface design and complex user interactions are better described by other techniques including design sketches, mock-ups, scenarios, and storyboards. Complement your user stories therefore with other techniques, and don’t feel obliged to only use stories.
A user story tells a story about a user interacting with the product. Some stories, however, omit the beneficiary altogether, or they talk about a mysterious user as in “As the user, I want to …” But if it’s not clear who the user is, why should the story be developed? How can we be confident that the story will benefit someone?
Make sure that all your stories have a clear user or customer. As I like to work with personas, I use personas in my stories (instead of user roles). This connects each story to the right persona, and it allows me to understand if and to which extend the story addresses the persona’s need or goal. To achieve this, I use the following template: As <persona>, I want <something> so that <benefit>.
The devil is in the details: Some stories are too big and vague for the team to understand and implement. Others contain too much detail, or even prescribe a solution. To get the level of detail right, start with big, coarse-grained stories called epics. Epics are like bullet points: They allow you to capture an idea without committing to the details. Then break an epic into more detailed user stories by involving the development team and leveraging user feedback on early product increments. Eventually, the new user stories replace the epic. Pay particular attention to the stories that are pulled into a sprint. These stories be ready: clear, feasible, and testable. Make sure, though, that you do not prescribe a solution in your stories. Rather focus on the “what”, nor the “how”. The latter should be decided by the development team.
Some product owners diligently write user stories, and give them to the development team in the sprint planning meeting. This handoff is usually suboptimal, as it wastes the team’s ideas and knowledge. Stories can hence be inappropriate, difficult to understand, unfeasible and not testable.
User stories, however, are not meant to be standalone documents. They should be complemented by a conversation between the product owner and the team, or even better: written collaboratively. A story wants to capture the essentials, and not specify every detail. The latter would be difficult for new features and too slow and too expensive in an agile / lean context.
User story writing should be a team effort, where product owner and development team create the stories together. Allocate time for a collaborative Product Canvas workshop or backlog grooming meeting, particularly when you develop a new product or new features. Trust me: Better stories and a better product will be your reward.
Acceptance criteria are maybe the most misunderstood part of users stories. I have seen detailed stories with no acceptance criteria, criteria that restate the narrative, and criteria that hide new stories, or even contain entire workflows. The last two mistakes are exemplified by the following story (the narrative is on the card on the left, the “acceptance criteria” on the right):
The idea behind acceptance criteria is simple: They allow you to describe the conditions that have to be fulfilled so that the story is done, that it can be exposed to the users and the other stakeholders. This ensures that you gather feedback and/or release features, and it helps the team plan and track their work: The criteria enrich the story and make it more precise and testable. (The criteria all stories have to fulfil such as “online help is available” are not stated in the acceptance criteria but in the Definition of Done.)
As a rule of thumb, I like to work with three to five criteria per story, and I am not worried if my epics don’t have acceptance criteria to start with. Ready stories, however, must provide meaningful criteria. You can find sample acceptance criteria in my posts “Epics and Ready Stories” and “Nonfunctional Requirements“.
As markets, products, and technologies change at an ever-faster pace, strategies that used to last…
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
View Comments
Where does "common sense/best practice" fit in a user story? On many occasion I have raised questions in sprint review as to why something has been done the way it is (or rather - why is something NOT done). The response has often been that there was no acceptance criteria asking for it to be done any other way.
These things include - scroll bars missing from a list page (how does the user scroll if their mouse has no scroll wheel?), a list of typo issues being addressed, but only the exact ones mentioned - others that were missed, but still obviously wrong were excluded, combo boxes being sorted by database ID rather than alphabetically. (how does the user find what they are looking for).
The user story and it's acceptance criteria (in my view anyway!) should cover the explicit business requirements that are related to the piece of functionality. Best practice should be assumed (worse case a quick message from the developer to the PO validating assumptions).
The user story becomes a mini waterfall functional specification if every single button and detail has to be documented, diagramed/mocked up otherwise?
Is it just me who has the wrong understanding to user stories and their acceptance?!
In regards to Ian Courts comment "where does common sense / best practice fit into user stories". I've been working as a software developer for over 20 years and I would say it doesn't. Everything should be specified, although if certain practices are done by default in your application there should be a number of documents that can be referred to such as coding standards, design standards etc which state this and will avoid having to specify the same requirements and a default for the developers to revert to if not otherwise specified in the story.
Where best practice is used, each team member should be aware of why it is best practice, as no best practice is applicable in 100% of scenarios and can lead to unnecessary system bloat by following it blindly. This is where common sense comes in to understand if this practice is required in the specific scenario. I've seen companies spend hundreds of thousands of pounds developing software following best practice that has then gone unused because it is not actually fit for purpose.
Ideally, developers will have a clear idea of the problem being solved and will raise any concerns as part of backlog grooming /refinement and if they do, hold onto those developers as they are worth every penny. Unfortunately, with the trend of out shipping development to cheaper countries, often these contract developers don't have a vested interest in the product and will just follow instructions by the letter, and even Roman's advice of writing stories together doesn't always fix these issues. In these situations, nothing should be left to chance. Something that you think is common sense, may not be common sense to someone else so create documented standards for your developers to follow.
Thanks for sharing your perspective, Dave. I agree that if developers have no knowledge about the problem to be solved and the users of the problem, applying user stories will be challenging. The solution, in my mind, is to involve (some of) the development team members in the strategizing work rather than opting for a traditional requirements engineering approach. Hope this helps!
Thank you for sharing your question Ian. It sounds to me as if you and your development would benefit from joint user story and product backlog work: Ideally discovering and refining together but at least, ensuring that you discuss the user stories with the team before the they are worked on. This creates a shared understanding of the functionality that needs to be implemented. If you already collaborate on the user stories but you still experience the issues you described, then explore their causes in one of the next sprint retrospectives. It might be that the dev team lacks domain knowledge and you therefore have to capture all error cases at least for now, or it might be that people lack motivation and are not fully committed to the product, for example.
Does this help?
Could you please elaborate on Acceptance Criteria? Sometimes my acceptance criteria just looks like a duplication of the user story. Help.
Thanks for sharing your question Debbie. You are right: A common mistake is to restate the narrative in the acceptance criteria. One way to discover the criteria is to ask, "How will we know that the story is done?" and "What conditions need to be fulfilled so that the functionality described in the narrative has been successfully implemented?" Testers tend to be great partners to find the right acceptance criteria. Hope this helps!
Hey Roman. I found your articles very helpful in understanding what user story is. Can you please elaborate more about disastrous details? I mean, technical approach, description of the functionality are major attributes. And, Is it suitable to add work flows, process flow diagrams in user stories?
Thanks.
Hi Syed Mehdi,
Thanks for your feedback and sharing your questions. I prefer to capture user interactions as separate artefacts, for example, workflow diagrams, scenarios, and storyboards, rather than adding them to the narrative or acceptance criteria of a user story. Please see my article "User Stories are Not Enough for a Great User Experience". Having said that, I recommend that your stories capture end user functionality and focus on the what, not the how: How a user story is implemented should be decided by the development and described in form of an architecture model, for instance.
Hope this helps!
Great feedback
Roman, your blogs are really helpful in understanding agile concepts. Recently I have come across a term "job stories" in one of the article. Would it be possible for you to write/elaborate on job stories vs user stories and their applicability?
Thanks
Thanks for your feedback and question Abhinav. I haven't written any job stories to be honest. I tend to use personas to describe the users and the problem they want to see addressed, and I employ user stories to capture the solution that helps solve the problem. But I'd encourage you to experiment with job stories and see how they work for you.
Oh, now I get it! Thanks!
The sample story in Criteria Crisis suffers from the problem described in User Incognito. I'm so confused!
That's the trouble with bad user stories: They attract multiple mistakes ;-) Sorry if the sample story left you confused. I have changed it, and I hope it's clearer now.