What is a User Story? If you embrace DevOps, you need to know that. Despite its simplicity, not everyone has a clear idea of what is a user story. However, grasping this concept will enable you to create a smoother and better software development process. In other words, you will create software faster, and with strict compliance with the requirements. How do you do that? This is the article to find it out.
Before we start, if you are new to DevOps you may want to start from here. However, that’s not a requirement. You don’t need any kind of knowledge or skill to understand user stories. Feel free to just keep reading.
What is a User Story?
Well, you guessed it, a User Story is a story from a user. A user story is just a piece of text describing a feature about a software or a system. We are not talking about technical specifications. Rather, it is what an imaginary user would say about your product once the feature is in place. We said an imaginary user because the feature doesn’t exist yet. In fact, the purpose of user stories is to clarify what are the features you are going to implement next.
So, you have to figure out how you wish your software to be, and then imagine users of it describing it. So far so simple. Try to keep your stories as short as concise as possible. Since user stories are from imaginary users, they should describe end-user features. In other words, they shouldn’t be about technical items. A user stories should not define which functions or classes to implement. Instead, it should define user abilities on the platform. How do we do that exactly? There is no specific rule, but using a template is the quickest way.
A template for User Stories
Knowing what is a user story may be enough if you are approaching DevOps and Agile development. Yet, user stories can be even more beneficial if you follow a template. In other words, you write all user stories in the same way. This is to ensure you always include the critical items inside your stories. Even if you don’t follow a template, a well-made story includes three items:
- Identification of the user (role)
- Description of the capability or feature the user gets
- Why it is important
Therefore, the following template will be good to describe your user stories.
As a <role>, I can <capability> and this matters to me <why>.
Breaking down the template
The role identifies the type of user, and it is important to understand the different stakeholders in your project. For example, imagine you are working on a platform like Uber, that connects drivers with passengers. You will have two roles, the driver and the passengers. The driver will want some features, while the passenger will want some others. Each will have its own reasons.
The capability is the description of the feature you offer to the user, plain and simple. For example, a capability or feature could be “I want to see where drivers are on a map”, or “I want to see all the invoices in my profile”.
The why is the why. It indicates why it is important for the user to have that feature, and allows you to understand the priorities. Based on that, you can plan which features to implement first. It also ensures you are only implementing features that actually matter, avoiding the feature creep. Thus, we can make two example user stories:
- As a passenger, I want to see where drivers are on the map. This matters to me because I want to select the drivers that are closer to me, and save time.
- As a driver, I want to see all the invoices in my profile. This matters to me because I don’t have to track invoices via email or other means, I can have everything on the same platform.
Start using User Stories
You can start using user stories immediately, now that you understand what is a user story. In fact, the only thing you need is yourself and a piece of paper. Even if you are a solo developer, start using them. This way you will adapt your way of working to this user story workflow. Later, you can expand and have real users writing user stories for you, and be ready to work in this way.
Of course, you can write user stories on a piece of paper. But that’s not how you get the most out of a user story. Instead, I recommend using tools where you can write stories on boards. One popular option and free option (with paid features you won’t need) is Trello.
If you are using Azure DevOps as your CI/CD system and possibly source control, use their boards. They are native in the platform, and they allow you to group stories into bigger features and also to destructure stories into smaller tasks.
Wrapping it up
What is a user story? A user story is a simple way to describe features you want to implement in your software. With their structure, user stories allow you to focus only on what matters most to the user and are easy to implement. It is no surprise that many development teams are embracing this approach. What do you think about user stories? Do you see yourself using them in your next project? Let me know in the comments!
