As a fairly new user story writer, I have been reading a couple of books and working through the learning curve of writing good user stories (and the acceptance criteria that goes along with them). It’s becoming more and more evident that having well written user stories, with acceptance criteria, is directly correlated to a project running smoothly.
What are user stories?
This one question could probably be debated for a whole blog, but we’ll go with a simple definition from User Stories Applied by Mike Cohn:
“A user story describes functionality that will be valuable to either a user or purchaser of a system or software.”
Within Scrum, user stories are one of the key artifacts development teams use. The idea is to provide enough high level information and detail of a requirement that developers can produce a reasonable estimate to implement the solution. Cohn also suggests writing them with a more formal approach using this formula:
This approach allows you to think about how the feature is built and why. There are many approaches you can try and trial and error can help you determine the best approach for your team. Make sure your user stories are always written so that they are understandable by both business and technical individuals.
Who writes the user stories?
Many different roles within an organization can be responsible for writing user stories, but the key is the person writing the user stories is representing someone important to the end solution, like the stakeholder, customer, or an end user. Ultimately, Product Owners own the user stories and are responsible for writing, gathering and prioritizing them.
Guidelines for Writing User Stories
Have a meaningful goal
When writing your user stories identify the user roles and their goals. This will help you create high level stories. Which in turn, you can begin to break into smaller stories. Just remember the stories need to have some sort of functional meaning, there needs to be a way to “test” that the story has been completed. The story should have a meaningful goal, allowing the user to feel that something has been accomplished. One thing I keep forgetting is that the story should not include a solution. Really, as the Product Owner, I don’t necessarily care how they get to the end goal as long as the goal is met and testable. I have to continue to keep in mind that I just need to right the user role and goal, not how to accomplish the goal. It really only adds confusion for the team. The team can look at the goal and the acceptance criteria and then task out the solution.
Ensure the work can be completed in the sprint
You can also focus on more short term stories, making the story a size that would allow the team to complete it within the next sprint or iteration. For stories that are a little further out, you can still create them, they can also be a little larger and less precise. Then as you get closer to working on those stories being worked on, go in and re-write them to make them smaller and more precise. And, of course, always communicate with the appropriate parties and add detailed acceptance criteria. At the end of the day, each story/iteration should deliver business value to the stakeholder(s). If it doesn’t, it’s considered incomplete and should not be included in the sprint.
Think about the End User
Adding to the idea of user roles, most people find it helpful to write stories with users in mind so that as the project begins to get developed everyone is thinking about the actual end-user. Such as a Marketing Manager or IT Manager, they can imagine an actual person vs. a “user”. Also, if you can focus on one user, that may make things easier to read, but there will be times when you have multiple roles and it makes sense to write for multiple roles. You can also focus on the problem that needs to be solved. Either way, using a persona or a fictional character as your end user will help visualize the functionality needed to meet the goals of that persona. Another common mistake (or 2) is to write a user story as the Product Owner or as a Developer. These types of stories aren’t actually helpful. They don’t represent value to the customer as the story, which may be relevant and needed, doesn’t deliver business value at the end of the story. You can include these stories, just make sure they are written from a persona’s view.
Use an Active Voice
Also, using an active voice makes the user story easier to read and understand. This also goes back to using the “As a (role) I want (something) so that (benefit)” approach. It allows you to understand what the active user wants to do and what the outcome should be. Keep the stories simple and concise. Try to leave out non-essential information, which isn’t always easy, but sometimes less is more! Another key thing to remember, don’t speculate. If you don’t know what the user is trying to do with the product or how they will use it, you should take a stop a back and observe (if possible) and/or interview the appropriate users/customers. The user stories need to be based on relevant knowledge.
The End Result
The bottom line is that the team needs to understand the story, conversations should happen around the story and a test to confirm the story has been successfully completed. User Stories evolve by interviewing users, observing users, questionnaires and conversation. Usually, you can achieve the best results when you combine a couple of these methods rather than focusing or over relying on one. The interaction will really help solidify the goal of the user, therefore providing a better understanding to the user story writer. Also, as you move through the project, User Stories may change. You may find you don’t need one or you add 2 more, or re-write a handful based on what you have built and what you now know. That’s the great thing about being Agile, it doesn’t bottle neck you. The team can make adjustments on the fly, be flexible, be agile. You can re-order stories if needed too. There is no single recipe for User Stories, but I hope I provided some background on how to write good user stories for your team. As a final reminder, the story should be independent, valuable, estimatable, fit in one iteration and testable. Save the detail for the acceptance criteria and the tasks associated with the story. Hope you found this post helpful!