How we write user stories at UPDIVISION Bucharest

How we write user stories at UPDIVISION
Bucureşti
Bucharest, Romania

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 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:

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:

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
-
- 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:

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:

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
- 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:

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
- 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.