Cheryl Henderson
May 05, 2016

The Importance of Writing Good User Stories

Cheryl Henderson

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:

User Story 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.Scrum Board

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!

1 Comment

  1. 1 Chris 17 May
    Trying to avoid solution development in User Stories is a frequent challenge.  It's always tempting to start trying to solve the problem at this stage, but that's not really part of what user story development is all about.  Right sizing them is another big challenge.  It's sometimes hard for business users to not attempt to provide excruciating detail, thinking that doing so will add value to story and help the dev team.  In reality it tends to be constricting and often more confusing.  However, finding the balance does indeed lead to better software and happier clients. 

Comment

  1. RadEditor - HTML WYSIWYG Editor. MS Word-like content editing experience thanks to a rich set of formatting tools, dropdowns, dialogs, system modules and built-in spell-check.
    RadEditor's components - toolbar, content area, modes and modules
       
    Toolbar's wrapper 
     
    Content area wrapper
    RadEditor's bottom area: Design, Html and Preview modes, Statistics module and resize handle.
    It contains RadEditor's Modes/views (HTML, Design and Preview), Statistics and Resizer
    Editor Mode buttonsStatistics moduleEditor resizer
      
    RadEditor's Modules - special tools used to provide extra information such as Tag Inspector, Real Time HTML Viewer, Tag Properties and other.
       

Subscribe to Our Blog

Get the latest blog posts sent right to your inbox so you never miss an informative post from Mercury.

 

Get Your Share On!

 

Tags

Archived Posts

Go here to find all blog post published before the new year.