How we write user stories at UPDIVISION

User stories are a key part of building software. Through these, you can map out specific development tasks, requirements, and you can also use them as a guide when testing apps once they’ve been built.

An app’s user stories describe every little action that happens in it, plus what criteria determines if that action is acting up to par or not.

User stories, thus, guide developers especially: when you describe each action in detail, they’ll know what to build in code. Otherwise, you’re leaving it up to their imagination - or begging them to ask you millions of questions.

At UPDIVISION, we’ve perfected our method of writing user stories over the years. We’ve constantly updated it according to industry changes, our experience and development needs.

So in this article, we’re going to tell you how we write user stories, and why our method works (for us).

How to write user stories for software development projects

User stories use a very specific formula: As a [user] + I want [intent] + so that [value]. Using this, you can pinpoint:

• The user type the story applies to. It can be a regular user, an admin, or specific user types you invent for your app (such as: employees, store managers, customers, and so on)

• What you’re building. The “intent” part signifies what feature the user story is about. For instance, you might want to log in, or change your password.

• Why you’re building it. Here you can provide details such as how this feature helps the user, or just a simple reason why. You’re logging in so that you can access account data, for instance.

The main part of a user story is composed of this formula. But in our case, in order to help with testing, we also provide a section for acceptance criteria.

Acceptance criteria give a more detailed scope of a user story’s requirements. They help us understand what needs to be built, exactly how it should work, and what results the users will get. Most of all, they help developers code exactly what’s needed.

Through acceptance criteria, a quality assurance team can more accurately test whether a feature works as intended or not. It can serve as a testing plan & a way to check implementation.

Acceptance criteria should:

• Clarify what the developers should build before they start coding

• Ensure a common understanding of the problem or needs of the customer

• Help team members know when the story is complete

• Help the QA team understand what the test flows should be

Confused? Here’s a realistic example of a user story that includes acceptance criteria:

As a potential conference attendee, 

I want to be able to register for the conference online, 

so that I can attend.

Acceptance Criteria:

• Conference Attendance Form

• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)

• Information from the form is stored in the registration database

• Protection against spam is working

• Payment can be made via Paypal, Debit, or Credit Card

• An acknowledgment email is sent to the attendee after submitting the form

Aside from the formula and acceptance criteria, we often add specific technical tasks. In this case, developers come in and add specific backend and frontend tasks related to the main user story, which can help them estimate the entire story easier and which can serve as a guide during implementation.

Why do we need user stories?

Writing user stories takes a lot of time and effort. At first glance, it might seem like too much work for a much-too-small reward. But in reality, user stories help map out functionality and ensure they’re going to be built correctly.

Here are specific ways we make use of user stories:

• Composing development tasks in ClickUp or Jira. Our user stories template is formatted in such a way that we can import it into task management tools such as ClickUp (the one we use). Each task will contain all essential information and acceptance criteria that can be used during testing.

• Mapping out a project timeline. We often use user stories to split projects into phases. You can create different files for each phase or separate them into sheets if you’re using Excel/Google Forms.

• Guiding the QA team in accurately testing features. The acceptance criteria helps testers know exactly what to check, what to look for, and how to determine if a feature works or not.

• Mapping out functionality. The main thing user stories are used for is describing an app’s features. It’s a great way to go into detail about what your app should do, and to prepare it for development.

• Creating cost estimates. In our case, we often start software development projects with UI/UX design, and then we move onto writing user stories and estimating each task, so we can give a budget for the whole project. With user stories, developers can more accurately estimate a project, especially the more detailed they are.

Thus, as much as they might seem tedious, user stories are very useful in software development. In fact, they’re a staple in building software.

What do you need to write user stories?

Generally, there are 2 big ways you can set out to write an app’s user stories:

• Basing off of a concept, or desired user flow discussions.

• Creating the app’s design first, and using them as a base for user stories.

In our case, our 15+ years of software development experience have taught us that designing first is much more useful. In fact, we’re written before about why design-first development is better.

When you design an app first, you’re mapping out all the user flows and features in detail before even thinking about development. Once you’re done, you not only know what your app will look like, but also how it’ll work. It’s a great base for development, and especially for user stories.

In our process, once we’re done designing an app, and it’s approved by its stakeholders, our next step is writing user stories. Since all the features have been discussed and visually mapped out, writing stories doesn’t take that long and are bound to be accurate.

Plus, having a visual reference such as a completed app design is a great way to help developers understand what they need to build - and of course, what it should look like.

With design done, the frontend part of user stories is much easier to map out: you already know the exact page layout and overall look. Plus - this helps with estimates.

If you write user stories without a design, and just using a concept:

• You won’t be able to go into too much detail, except for obvious tasks such as signing up.

• There won’t be a visual reference for any of the features

• Your final development estimates won’t include the full frontend costs

• They’ll take longer to write, as you need to carefully think through each feature.

And so, to write an app’s user stories, you need to at least have a clear idea of what you’re building, or best of all - an entire app design.

Who should write user stories?

If you’re doing design-first software development like we are, you want your design team to be in charge of user stories. It might seem like you’re taking them away from other important tasks, but they hold all the information needed: they’ve done the user research, they’ve talked to the app stakeholders, they’ve thought over the entire user flow, and know the ins and outs of the app the best.

Alongside your design team, you can ask developers to chime in and add details where needed, such as the technical tasks from our user stories template. They can do this during the estimation phase as well.

If you’re starting off without a design, project managers tend to have useful skills that can help them write user stories. They know what development tasks look like, they know the project, and they know enough about software development to figure out what kind of details to write into each user story.

Alternatively, user stories can be written by product owners or any stakeholder that knows the project well enough. This works if you don’t have a working design yet, and a small team looking to scale up. If you’re part of such a team, looking at user stories examples and following that should help your team learn.

All in all, our recommendation is to design your app first and write user stories after. This guarantees that all the features are written out accurately, with all their components, and they can be estimated realistically.

Overall, writing user stories can look difficult at first, but once you get the hang of it, it’s like riding a bike. Every project is unique, and the key to writing good user stories is being open to communicating with your entire team, especially the developers you work with. Developers will know what serves as an individual user story and what needs to be broken down into multiple.

In need of help? We can tell you more about writing user stories or even build your entire software from the ground up. Let’s chat and see what we can do together.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.