How Non-Technical Managers Can Write User Stories

May 17, 2019

A quick guide for non-technical managers on how to create useful and effective user stories that boost team productivity. 

A well-written user story makes the whole software development process easier to follow. A user story offers a user-focused system for daily activities and is the core component of an agile development program. 

If effectively used, user stories contribute to teamwork structuring and time savings. However, it frequently turns out that the process of building useful user stories is not as easy as it seems to be. 

Unclear goals and messy descriptions disrupt the work within the project. If you want to avoid common mistakes and go through the writing phase quickly and smoothly, use the helpful tips found below. 

1. Remember the Basics

Every well-written user story covers the basics of the subject. Therefore, always keep in mind that the main goal of a user story is to describe functionality that will be valuable for either the user or purchaser of a system or software. 

Companies use the following structure to keep stories simple and concise:

As a <your role>, I want <your goal> so that <benefit>. 

User Story Template
 Use this template when it is helpful, but don’t feel obliged to always apply it. Experiment with different ways to write your stories to understand what works best for you and your team.

2. Begin With Goals for Large Projects 

On large projects, especially when you have to consider various user roles, it is frequently difficult to even know how to create user stories.  

What works best in such situations is to consider each user role separately and identify the goals and objectives that specific users have when interacting with developed software

Afterward, these goals (which, in fact, are high-level stories) can be used to create additional user stories as needed.

3. Take Advantage of User Role Modeling

Identifying user roles and personas prior to writing user stories can bring great benefits to the team and boost their performance.  

On many projects, stories are written with the assumption that there is only one type of user. This simplification can easily lead the team to miss many stories for those users who do not fit into the scheme.

To avoid this and identify a useful set of user roles, brainstorm possible user rules, organize your ideas, consolidate the list, and refine as needed. 

4 steps to identify user roles include brainstorming, organizing, grouping, and refining.

This role defining procedure will allow you to indicate all the users you need to take into account when creating user stories. Remember to always engage all the necessary team members when proceeding with these steps. 

4. Write Closed Stories

Soren Lauesen, executive director of Mattel Inc., the global toy brand, is known for preaching the value of task closure and the steps it takes to feel satisfied with work.  

This same concept can be applied to the software development process. 

The idea is to create stories that finish with the definite achievement of a meaningful goal and that allow the user to feel that something has been accomplished. 

For example, rather than creating a story such as, “a recruiter will create job postings” it would be better to restructure the story into a set of closed stories that have definitive endings. 

These closed stories could be: “A recruiter will read the resumes of applicants who viewed the job posting s/he created,” or “A recruiter will delete an application that doesn’t fit the requirements s/he outlined.” 

Completion of any of these stories would bring the user a sense of accomplishment and goal achievement.

When writing closed stories, it is crucial to remember other constraints. Stories need to be small enough to be achievable and conveniently fitted into a single iteration but at the same time, general enough to avoid capturing unnecessary details.

5. Include User Roles in the Stories

To keep the user at the forefront of the team’s (and especially developer’s) mind, it is very useful to identify the user roles and write them into the user stories. 

Instead of writing, “a user can log into the panel” it’s better to write “A job seeker can log into the panel.” 

The difference might seem minor, but it makes developers think of a real, tangible user who they need to satisfy with the software

This approach is also coherent with the first tip and presented scheme: As a <user role>, I want <what?>, so that <why?>.

6. Don’t Forget the Purpose

The main goal of the story card is to remind the whole team what the purpose of a given feature is. 

Keep this in mind during implementation and make sure to reiterate it briefly every day. 

You can obviously add necessary details to the card but never to the extent that it replaces the conversation in a team.   

7. Remember Customer Responsibilities

As a developer, you have a lot of responsibilities when creating user stories. 

You are in charge of writing stories that make promises to the customer. You always have to put the value of the user over your own desires. Instead of writing technical stories with minimal business value, like “add a favorites button to the UI” (frontend issue) and “save the podcast id to the user’s account” (backend issue), it’s better to write “users should be able to add a podcast to their favorites.” 

As for user role-modeling, you are responsible for looking broadly across the space of users and identifying possible user groups and establishing buyer personas.  

You should also think about how different types of users may prefer the software to work. 

8. Be Aware of Developers Responsibilities

To complete the user stories creation phase with success, you have to be aware of what developers should do and their responsibilities. 

First of all, the developers' team has to help you in establishing stories that are testable and appropriately-sized. For example, “a recruiter will delete an application that doesn’t fit the requirements s/he outlined.” 

Likewise, developers have to make sure that describing user stories do not go beyond their role as simple tools in the development process.

9. Put Constraints on User Stories 

J. Newkirk and R. Martin in “Extreme Programming in Practice” proposed a practice that seems to be very useful when it comes to creating good user stories. 

They recommended a method of annotating a story card with a “constraint” for any story that has outside considerations. 

Good examples of such constraints are: “Do not make it hard to internationalize the software if needed later” or “The new system must use our existing transaction database.”

Such constraint cards do not get estimated and scheduled but should be considered when making acceptance tests to make sure that none of them are violated.

10. Avoid Common Mistakes

The most common mistake when writing stories is to express everything that is developed by the team as a story. 

This results in very technical stories that capture user interface design, complex user interaction, and technical requirements. We need to remember that, like any technique, user story writing has its strengths and limitations. 

User interface design and complex user interactions would be better described by other techniques, including design sketches, mock-ups, scenarios, or storyboards than by user story technique. 

Thus, complement your user stories with other techniques, and don’t feel obliged to use only one method.

The other mistake is the so-called “incognito user.” 

A user story has to describe a specific user interaction with the product. However, it’s very common to talk about a mysterious user in the pattern: “As the user, I want to …” 

In that form, it’s not clear to anyone on the team who the user is and why the story should even be developed. Want to avoid this? Follow the rules described in tip 4 to become a master in user role modeling.

Further, some stories are too big and vague for the team to be properly understood and implemented. Others, however, contain too many details or even prescribe the solution. 

So how do you avoid these mistakes? 

The best way is to start with big stories called epics. Epic stories will allow you to capture an idea without committing to the details. 

Then, you should break the epic into more detailed user stories. The new user stories replace the epic, and they provide more information about the product’s functionality. 

Write Effective User Stories 

Writing good user stories, like any other skill, depends on experience. 

To become an expert, you have to evaluate your own work style and check what is most valuable for you and your team. Consult with an experienced software development company to learn more about how to create effective user stories. 

Thus, experiment with provided tips and techniques and adapt them to your needs.