What are user stories, and who should write them?
If you are engaged in software development, you must have heard of user stories. Perhaps you even write them as a manager. Or maybe you’re a client and your software developer wants you to frame feature requests as user stories.
In this post, you’ll find everything you ever wanted to know about user stories.
What’s a user story in software development?
A user story is a format for framing software features and/or requirements. As the “user” part suggests, user stories are written in first person singular and describe a feature as it is perceived by the app’s user.
A typical user story follows this structure (if we’re talking about the Agile development process):
As a [user role]
I want [this-and-this feature]
So that [this-and-this effect is achieved]
The first part (as a…) specifies the user’s role in the application, which is normally associated with what one is allowed to do there.
The second part (the feature) points to the piece of functionality that is used in this case.
The third part (the desired outcome) is the value the user wants to get out of the feature. Here are some examples.
Example 1
As a registered user
I want to be notified when a friend is going to an event nearby
So that I can react to the news or join them in the event.
Example 2
As a rider
I want to get a 10% discount on every 10th trip
So that I get rewarded for consistently spending money on the service.
There are sound reasons for this kind of structure. When product/project managers deal with software requirements that come from a variety of sources, it is sometimes difficult for them to attain uniformity. Which category of users the feature covers or where the business value lies may also be unclear. The user story format helps capture these critical details.
Approaches to composing user stories
User stories can be written in a variety of ways, depending on who’s going to work with them.
The Gherkin way
Gherkin is a plain-text language that describes behavior without specifying its implementation. Here is a simple example of the Gherkin syntax:
Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website
Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article
Scenario: I edit somebody else’s article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button
As you may have noticed, indent defines structure in Gherkin. The basic parameters are Given/When/Then, and these can be appended by multiple And’s if necessary. The syntax goes beyond these basic parameters, though. If you’re really determined to master Gherkin, here’s a nice tutorial.
While Gherkin may not be the best choice when you’re gathering initial requirements for the project, it can be beneficial (especially for the QA team) when further developing user stories. User stories written in Gherkin are easy to convert to test cases.
The Agile way
Many Agile project management applications offer a functionality for entering user stories. For example, we’ve used the Taiga app on some of our internal projects. It helps you organize work around user stories that can be broken down into individual tasks in the backlog.
If you think about it, it makes perfect sense to have user stories as backlog items and then add multiple tasks to one user story. Why? Because, let’s say, you have one feature (=user story) and three people working on it; so, you’ll need separate tasks for those people. You’ll need a designer to design the interface, an HTML/JavaScript programmer to program the interface, and the DevOps to release the interface into production.
Other tools like Pivotal Tracker (that introduces the concept of “epics” to group related stories together) also let you create stories that can be of different types: Features, Chores, Bugs or Releases.
Apart from the various approaches used by various companies, remember that there’s a simple and straightforward way to word user stories – examples of which you saw at the beginning of this post.
Who should write user stories
So, whose responsibility is it to write user stories? Well, it depends. If your team has agreed to capture features in the form of user stories, it is most likely that they’ll come from the shareholders through the Product Owner. So, it may be the PO who actually pens them down.
It could also be a Project Manager or a QA who may also work with the client to discuss features and requirements. Or, maybe you’re a 15-person startup and you are the CEO, CTO and CMO? In this case, you could set an example and start using user stories to document features.
Many in IT also talk about “user story development,” which is the process of registering high-level details first (e.g. starting with a simple list of features) and then developing them into more detailed stories by adding tasks, scenarios, etc.
In conclusion
At the end of the day, formulating features in the shape of user stories helps you stay focused on the business objectives. It also helps you make the requirements complete. And, as was said, the exact template/fields you use could be different, depending on the situation.
Related Blogs
Project Management Glossary: 33 Essential Terms
LEARN MORE
13 Agile Project Management Tools for Developers
LEARN MORE
