The importance of user stories in software development
Telling stories is how history and tradition have been passed along from generation to generation since the beginning of time. It’s part of being human. Stories help build strong relationships and draw in your audience.
In software development, the origin story of the team and the ideas behind a product are essential to getting buy-in and proving credibility. When building custom software, it’s crucial to understand the users’ pain points and their journey in order to build a product that truly solves their problems and makes their lives better. Knowing who is using the product is core to understanding the purpose behind a new build. User stories are vital in breaking down the overall vision into manageable pieces of work that are focused on the end user.
What is a user story?
For those new to the concept, a user story is a small piece of work that is supposed to focus on the end benefit delivered to the user once the story is complete. It’s a means to describe the purpose of a feature in a way the engineering team can understand. It’s also used to provide an estimate on the amount of effort it will take to finish the detailed requirements with the story, often called acceptance criteria. A user story is a core tool for product managers, engineers, and anyone working within an agile software development environment. (Quick caveat: This post is not focused on agile software development, so for more insight into Devbridge’s philosophy behind that, check out our post here).
There are many variations of the “proper” format for writing a user story, with the most common template looking like:
This starts with a particular user of the product/application (in some cases, applications have many different users or roles) and outlines what the user wants and why. For example, if a store manager needs a new scheduling system to save time, the user story might look like:
As a store manager, I want a new way to manage my employees’ schedules so that I can spend less time every week doing it by hand.
Another popular format shifts the focus from the user and onto the business outcome:
For the same use case, the store manager user story would look like:
When I am managing my employees’ schedules, I want to spend less time doing it by hand so I can spend more time focusing on business development.
This is a more appropriate format when you are trying to communicate the “why” behind building a feature. Keep in mind: The story can’t stop at the title. UX and UI design are essential parts of building a user-focused application and are necessary to visualize what the end result of the story should look like. (I’m not a designer, so I won’t comment on wireframes vs. mocks vs. final visuals…but you get the idea).
Even with designs and appropriate acceptance criteria in a story, it’s easy to lose sight of the rationale behind the build. Why should I, as the engineer, care about this feature? The goal of a user story is not to tell the engineering team how to build a feature, but rather to define what they’re building.
How to write better user stories
The benefits
Often, user stories are too simplistic. The benefit (or the why) often gets dropped from the user story altogether. For example, if you don’t know that the store manager is trying to save time, you might end up developing a wizard with multiple steps instead of a simpler, more straightforward approach.
A common example of an overly simplistic user story is, “As a product manager, I need analytics.” This does not capture why analytics are indeed valuable for the end users. Defining why will help the product team deliver the benefit by prioritizing new features and iterating based on actual usage of the application. Similarly, software/test engineers will write stories—just so the work is accounted for. These types of stories are limiting in that they’re usually much more focused on the features and technical implementation vs. the end user benefit.
The big picture
Understanding the big picture is crucial for user stories and experiences. What is the expected outcome for the user? What is the call to action for the users? What are their expectations? If you get caught up on the specific design and development of one particular feature, it might end up not fitting in with the larger platform, and you run the risk of ending up with a siloed product. Estimating an individual user story should not be done in a vacuum. Engineers should be invested in the vision of the product and understand the big picture. When the whole team has clarity around the big picture/workflow, they are better prepped to execute on how each feature should be built, as well as how that connects to the overall build. As an added bonus, the team has a sense of ownership and accomplishment once the story is complete.
It’s no fun feeling like Lucille Ball in the famous chocolate scene: unable to keep up with the work being thrown at her and not knowing what happens with the chocolates when her part is done.
The user journey
Yes, user stories are supposed to be entered and treated independently (i.e. using Jira) so that each story can be worked on in any order and can be estimated on its own. However, in my experience, it helps to understand the user’s journey. How do the users get to each screen, and where do they go after they’re done in a certain area of the app? If you don’t account for application-level navigation, the users might end up down a rabbit hole of drilldowns where they have to repeatedly hit the back button to get back to the starting place.
Using the store manager example above, if an engineer is building out a screen to submit a message from the manager to an employee, it would be helpful to know where that message goes and what information is relevant for other screens in the message workflow. The user might want to view a history of messages between the manager and employee or easily copy and paste messages to other employees.
The whole experience
When we kick off a project with a lean requirements workshop, we define success metrics for the entire product – not for granular user stories. Having a connected experience, as well as having the full team understand this experience, is crucial to executing on the vision. If you know that the entire platform is supposed to have a performance SLA of 0.4 seconds or less, you’ll know that you can’t build a screen that relies on multiple API calls that require calculations on the fly, as the performance will likely be too slow.
Individual user stories are usually tied to epics, which are larger parents or categories of features. These can help relate the individual story to the overall experience, but it’s easy to lose sight of why that particular story is essential to the core problem the application is solving. Similarly, when thinking about what success looks like, KPIs and metrics are based on the overall application – not a small piece of the puzzle.
Acting on emotion
The best way to get someone to take action is to make them feel invested in the outcome, to feel an emotional connection. One shining example of this for me comes from Craig Wortmann, a former professor of mine at the University of Chicago Booth School of Business. He told us about a lab study at Carnegie Mellon University in which two groups were given envelopes with five $1 bills and a pamphlet of information.
Half the participants received a pamphlet with facts and figures on all the people in Africa who had malaria and were suffering from other diseases. The other half of the participants received a pamphlet describing the hardship of a single person, a little girl named Rokia, who was dying from malaria. The participants with the second pamphlet donated more than twice as much as those who received the first pamphlet, not because they were more generous, but because they felt an emotional connection to Rokia, a human being.
Having a specific person in mind when building software allows the team to have that emotional connection. They’ll be more invested if they know the user in the user story. If you conduct user research at the beginning of the project, record one of the users talking through his or her current experience and how much he or she would benefit from what you’re building. Share this with the team so they have someone in mind whom they are building for. This experience from the user would be part of the bigger story and would help demonstrate why having that story is so important.
Stories help build understanding—and for tech features in particular, that’s understanding the meaning behind the information and requirements. You can use stories to help build trust with your customers and help them buy into the vision you are selling, which is a large part of product management. When the team understands the benefit of the product for users or even how not having the product is making things worse, this level of understanding can be a big motivator.
Using stories for better tech
Stories are important. They drive results, deliver outcomes, and motivate users to take action. To get from here to there, you need to understand your product’s users, their behavior, and their needs. User stories are very beneficial and useful tools for building software, and if used correctly, they can help build impactful end-user experiences.
To get the best results, pair user stories with an actual story that provides a connection to the end user and paints a picture of what is being built and why. Then, share the story with the build team so that you’re all on the same page. How? Record a video of yourself telling the story and make it readily accessible to your engineers, internal stakeholders, and anyone who needs to buy into the product. This way, everyone will have a shared understanding of what success looks like and why they should care upfront. Even better, as your team builds the app and features, you can make tweaks or alterations to the story based on the audience.
The bottom line…as a development team, we need to tell and use good stories so that everyone will benefit.
