What is a user story, and why do I care?

What is a user story, and why do I care?

Whether you are a business owner looking to speed existing operations with software, an entrepreneur trying to convey your vision to engineers and designers, or a seasoned technical veteran of software projects, user stories are a powerful tool to concisely communicate functional requirements across software teams. Understanding user stories, their usage and their limitations can provide another tool to help build valuable mobile and web software applications.

So, what is a user story?

User stories are one method of clearly communicating software requirements between business stakeholders and software development teams. More specifically, they could be described in the following manner:

User stories are clear, concise descriptions of features or functionality described from the perspective of the end user of a given software application. The user story describes the Who, What, and Why in language that can be understood by the end user.

At Grok, we have found that a good starting point for many stories comes in the following shape: "A [type of user] can [perform an action] so that [a desired outcome is reached]." In this short sentence we can answer the Who, What, and Why of the feature we want to build. Take for example the following user story for designing a front door:

A resident can see a person outside their front door so that they can determine if they should open the door.

In general, this story would be one of many, describing a set of features describing the door, the front step or even the entire home. For the sake of brevity, let us examine this story in isolation, to highlight the some of the capabilities and limitations of user stories. The following images represent potential ways we could fulfill the user story.

Door 1 Door 2 Door 3

What does a user story do?

User stories identify who will interact with the system

Our door example discusses two individuals, first is the resident. The resident is the user who we want to give a new capability. Also we have identified that another person is involved from the outside of the door. It is important to note that we intend to give the functionality to the resident though other people may benefit. Our home may involve other people such as a landlord, homeowner or guest, but we have not specified that they also need this capability.

User stories help establish and confirm a common language

To properly understand the story, anyone who is designing or building the door must have a shared understanding of a few concepts. Who is a resident? Which side of the door is ‘outside’? What do we mean when we say ‘door’? Take our previous images. All three doors permit users to see out, but not all would be properly suited for the front door of a home.

User stories provide basic acceptance criteria

In addition to encouraging a common understanding, the user stories also provide a checklist to the builder of a system to know that the end objective has been met. Let us look at each of our example doors against our user story. Does the door permit the person inside to look outside? Our example doors enable this functionality, but make it clear that some of these doors may be more appropriate than others, highlighting some of the limitation of user stories.

What are some limitations of user stories?

So now that we have highlighted some of the value of user stories, it is equally important to understand some of the limitations.

User stories do not dictate technology decisions

Our example user story is built from the perspective of the end user and permits the builder to leverage their expertise to know what materials and methods are best for the budget and environment. Specifically, talks from the person using the door, not the person building the door. Similarly, the selection of specific software languages, tools or platform is independent of the outcome for the end users.

User stories don’t dictate design decisions

In our example doors, we can see three different designs, using three different materials at likely very different costs and very different looks. In this example, it would have been valuable to build some sketches or see some other visual examples to help guide the design. Software is very similar; often software developers are less concerned with how something looks and more concerned with how something works. Supplementing well-written user stories with sketches or other designs can help us get to the look and feel that is desired.

User stories are not stagnant

If our house is built, and our door is installed. It is very unlikely that it will remain the same forever. Furniture changes, paint is replaced, floors are refinished, additions are added. Software and the user stories to describe them should be treated in much the same way. As our priorities and requested functionalities change, our stories should be revisited to ensure that they meet our needs the same way that our home meets our needs.

So now what?

Having now been introduced to user stories and their limitations, you now have another tool to help communicate with software teams to build better software and answer key questions. Who is using the system? What are their expected outcomes? When are they expected to interact with the system in their process? Where will they be when the are using your system? Why are they performing that specific action? Like any tool, they are one of many that can help create a successful project.

Categories: User Story, Business Requirements, Software Discovery | Tags: User Stories, Agile Development, App Requirements, Software Needs

Portrait photo for Brandon Beidel Brandon Beidel

Software developer, amateur welder, science and history enthusiast.



We provide a free consultation to discover competitive advantages for your business. Contact us today to schedule an appointment.