User Stories are the basis for all Scrum processes. These stories are the units of work that make up a project. They can be created by anyone and vetted by everyone. User stories come in various formats, and some are better than others. What you want out of a user story is a clear understanding of what a user or person wants to have done and why they want it done (goal). If correctly done, user stories can be handled by any developer and are immediately available to be worked. A suggested user story format follows a consistent structure that includes user story sentence, acceptance criteria, and possibly a mockup. This post will walk through the process of creating a user story and demonstrate some beneficial practices.

User Story Sentence

This sentence should follow the format below:

As a <role>, I would like <action> so that <goal>.

Three parameters: role, action, and a goal, are the substance of the sentence. The role parameter should be the role that will benefit from the goal of the user story. The action parameter should indicate what needs to be done to achieve the stated goal. The goal parameter is the value of doing the work. It is important that the role listed in the user story sentence be clearly defined. Often when you first start creating user stories, roles are defined as a user or as a developer. Such limited use of roles can hide who needs the work done and create issues downstream. To avoid these problems, try to be specific about which role needs the completion of this user story.

For example, consider the effectiveness of the role defined in the following user sentence:

As a user, I need to review new orders so that I can process orders efficiently.

Here, the use of “as a user,” while correct, does not help in the understanding of whom the story is for. Let’s say this user story is from a company that uses a warehouse management system. There are many workers at the company that use the warehouse management system, and this story is focused on workers who pull orders. We should change the role from user to warehouse worker to be clear as to whom the story is about. Updating the role to something more specific makes it clear to everyone who will perform the task and accomplish the goal.

As a warehouse worker, I need to review new orders so that I can process them efficiently.

Actions should also be precise, but be written in non-technical terms. You will want to make sure that you provide enough of a description so that the major points of the user story are apparent from reading the user story sentence. Try to avoid going beyond the major points here and instead use the acceptance criteria section for finer details. Let’s look at the example user story sentence again. For clarity, we should add what types of new orders need to be reviewed. Perhaps, there are three kinds of new orders: online, mail and in-person.

As a warehouse worker, I need to review new orders placed in-person so that I can process them efficiently.

The user story sentence is fairly accurate now, but the goal of “I can process them efficiently” is vague. How could you determine the return on investment for this story without having specific goals? Perhaps, someone in the business process improvement side has decided that a realistic goal for completing new orders in-person should be two minutes. We would include this defined goal in the user story sentence to explicitly set the goal we are trying to obtain.

As a warehouse worker, I need to review new orders placed in-person so that I can process them in 2-minutes to meet the FAST completion goal.

Now we have a great user story sentence.

Acceptance Criteria

Acceptance criteria are essential and should be included in nearly all user stories. The audience for these criteria is the individual working on the story and the person responsible for validating or testing the user story. This section is where the fine details about the user story reside. We will start with an example acceptance criteria for our current user story.

Acceptance Criteria (version 1)

Create a list of new orders

A developer could start to work on this, but there are two likely outcomes from this list of acceptance criteria. First, the developer completes the work, shows the product owner, and it is rejected, or he wisely asks for more information before he begins work. Perhaps there is a third option if the developer comes back with exactly what the product owner wants; however, the odds are not in favor of this occurring. To use an analogy here, this would be like asking someone to paint your house without providing any directions about the paint to use, the texture you want, or even the color, yet expecting a positive outcome (a positive outcome being a solution that meets your expectations). How do we fix this? We communicate our expectations, and that is where detailed acceptance criteria come in. Let’s change the previous acceptance criteria to include a commonly omitted item for these types of stories; the fields required. The updated acceptance criteria includes the fields we need.

Acceptance Criteria (version 2)

Create a list of new orders with the following fields:

  • Order Description
  • Order ID
  • Time Since Order
  • Order Date
  • Location
  • Quantity

If you were a developer, you could now create this list and meet these acceptance criteria. Of course, this does also require some implicit knowledge of where these fields exist in a database. While these new acceptance criteria provide detail, this list still needs some extra information, such as the order of columns. Specifically, the most important item on this list is the Time Since Order field because it is a key indicator of the goal we are trying to meet. Its placement in the middle of the list isn’t helpful, as you have to sift through other data to get to it. It also has an effect on how the list should be sorted. We would want the items getting close to the 2 minute deadline to show first in the list so that those processing the orders will see them at the top of the list and can clear them first. And while we are at it, the warehouse worker that this story came from asked if we could include a filter option to search by Order ID. Let’s make these changes to the COA with these new items.

Acceptance Criteria (version 3)

Create a list of new orders that contains the following fields in the order they are listed:

  • Time Since Order
  • Order Description
  • Order ID
  • Order Date
  • Location
  • Quantity

The list should be sorted by Time Since Order in descending order

Provide a filter option for search by Order ID

This acceptance criteria list is robust and can be given to any developer to complete it. But two questions should be answered before this could be production ready; how do users access the list, and what roles should have access to it. We will tack these on as well and add in the user story sentence to complete the user story.

As a warehouse worker, I need to review new orders placed in-person so that I can process them in 2-minutes to meet the FAST completion goal.

Acceptance Criteria (version 4)

Create a list of new orders that contains the following fields in the order they are listed:

  • Time Since Order
  • Order Description
  • Order ID
  • Order Date
  • Location
  • Quantity

The list should be sorted by Time Since Order in descending order. Provide a filter option for search by Order ID.

Add a link to the main menu under orders named In-Person Orders.

Secure form by allowing only the warehouse working role and manager roles access to the form.

At this point, we have defined a user story that could be released into production as long as it also meets the definition of done. The definition of done is determined by the team and, usually, lists additional acceptance criteria that a user story must have before going to production. Sometimes user stories cannot be released by themselves and are dependent on other user stories. There could be more acceptance criteria defined here as filter conditions, behaviors, validation, and color schemes, etc. These could be added to new user stories. What’s important here is we have defined a minimum viable product that’s ready for production.

Mockups

So far, we have been working on creating a user story with text. The result of this process is a form of an application. This process works, but for a lot of people, a visual representation will solidify their understanding of what is being built. For a visual representation, this is where mockups or wireframes come in. Their use will bring to light any concerns about the look and feel of the application, along with its functionality. It will also spur discussions about the design of a form.

Starting with what we have done here, please review the mockup below.

As you can see, it is pretty powerful to have a mockup of a user story to show the closest version of a form to the real thing. You could create the mockup before creating the user story as well. You don’t need to use a tool, and it could be hand drawn wireframes. However, if the mockups are hand-drawn you likely want to take pictures of them so they can be easily shared across distributed teams. It is suggested that most UI user stories include mockups, but for some stories, their use is not needed. You don’t need mockups for simple lists or forms where UI standards can be used to design most of the page. Not only do mockups provide a visual representation of a page, but they also provide for rapid prototyping and modification.

In the past, rapid prototyping meant creating an application quickly and demoing it. Then after the demo, changes requested would be noted, and a developer would make the changes. This process would repeat until the design was finalized. Such rapid prototyping was a lengthy process because the developer would often make changes to the database, then to the back-end, and then update the UI. With mockups, the only change is the mockup, thus shortening the turnaround time for change requests. For those that like the ability to enter an application and click around, there are many mockup tools today that will allow users this ability. In fact, many mobile applications are developed this way. It is essential to recognize the value of utilizing mockups for software development to shorten the iterative development cycle, to help visually centered learners, and to help provide a consensus of what is to be developed.

QA

We now have a user story that is detailed enough to be worked by any developer and can be used by QA to test. The QA team can review the user story for its purpose and the role it applies to, as well as validate the acceptance criteria. Using the mockup attached to the user story, a validation of the UI design can also be completed. QA can use the user story as a basis for all their test cases.

This article is not meant to be an example for all user stories. It is intended to exhibit what a well-defined user story includes and some items to considered when creating a user story. Using this user story structure for your user stories will help with clarity, transferability, and testability.

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *