User stories are a development tool that helps us understand your audience better to know what we’re building, why, and who it’s for. They are an essential part of any relevant and competitive IT product.
So, you’ve made it this far in your company’s incursion into the digital world, and you can’t wait to reap the benefits your new app will bring to your business. Now all you have to do is lay back and wait, right? Well, not quite. It’s tempting to think that once you’ve hired Foonkey Monkey to develop your product, we won’t need you until your product is ready. Luckily, that’s not the case. See, the first stage of the development of your app is where we determine the specs and write out your product’s requirements. This process is linked to your product’s users, their needs, and the impact it will have on them. No one understands these aspects and your users better than you. So, to contextualize ourselves, target your users’ needs, and help us determine the functionality from their perspective, we use something called user stories.
By now, you’re probably wondering why we asked you to write user stories. Why can’t we write them? Well, we do, but we also need your input and knowledge so that we can place your end-users at the core of every stage of our development process. This way, we can develop a user-oriented framework for daily work. In turn, the product will be more user-oriented, and the development process can be faster, saving money and time for all stakeholders. Additionally, user stories don’t require any technical knowledge, which allows you to better communicate with our development team and create a common ground, ultimately driving creativity and delivering a better product.
So, what exactly is a user story? Why and how do you write them? and is it even worth your time? (Hint: yes it is) Let’s find out.
What are User Stories?
User stories are informal descriptions of a product’s features and functionalities written from the end user’s perspective. They help us establish a clear view of who your app’s users are and what they can do with it. This way, our developers can be guided by this view and avoid implementing unnecessary, useless features that can cost you big bucks and have no value. We can pinpoint what your users need and want and build for those specific needs using your user stories. Are they life-or-death mandatory? Not really. Are they useful and valuable? You bet.
For instance, we might ignore user stories and develop a sophisticated app with AI-driven chatbots, sentiment analysis, and impressive design features and buttons. But in reality, all your users wanted was a solution for, let’s say, transferring money overseas. In this example, we would’ve used generic user requirements and would’ve probably gone overboard in costs and features.
With that in mind, user stories typically answer the following questions:
- Who is it for?
- What does it do?
- For what? (What value or benefit does it deliver)
Following these three questions, a suitable format for you to write your user stories would be:
- As a, I want, so.
User story examples
“As a banking customer (who), I want to perform transactions electronically (what it does), so I don’t have to wait in line at the bank (goal)”.
Or
“As a registered patient (who), I want to be notified when my cardiologist has an opening on their schedule (what it does), so I can book an appointment using the app (goal)”.
As you’re probably thinking, this approach to user stories doesn’t leave much room for detail, but that’s the point. User stories are meant to be concise, short, clear, and easy to understand for all stakeholders. In such a manner, instead of having to paddle through extensive details and countless demands, user stories provide a concise way for us to capture the desired functions of your product.
Nonetheless, If you feel the need to add extra detail to user stories, you can break down your main user story into multiple user stories. Your main user story will be less specific and is known as an epic user story. It will encompass a broad, more general functionality range. Subsequently, your epic user story will split into multiple smaller stories that specify more detailed functionalities. Sounds complicated, we know. Don’t worry; we’ll dive into this later on.
Why are User Stories Important?
We understand that our clients don’t know how a product should work most times, and why should they? That’s why they hire us in the first place. But even if you’re not aware of it yet, no one has a clearer understanding of your users and your market than you do.
Your user stories are important because they give us an easy, fast, and straightforward way to define your product’s features and functionalities. By writing out your user stories, you’re helping us articulate the relevant functionalities of your product so we can leave out unnecessary implementations and ground our development processes. It can also empower meaningful and inclusive product discussions because they have plain, simple terms that everyone can understand.
Technical terms don’t belong here, so you or any team member can contribute and be part of your product’s development by thinking as a user would. This efficient collaboration helps us achieve cross-team certainty on what to build, for whom, and why. This certainty enhances a team dynamic that can be significantly beneficial for all parties involved.
In short, your user stories matter to us because they:
- Eliminate gaps between you and the business and technical teams.
- Help us define the entire scope of the product and understand it better.
- Engage you, the client, in the development process.
- Help optimize resources and times.
Are You Ready? Let’s Start Writing!
So, now that you understand what user stories are and the value they add to your product, you’re ready to start writing them. But first, let’s take a quick look at what makes a good user story.
Good user stories typically match the INVEST model created by Bill Wake, where they should be Independent, Negotiable, Valuable, Estimable, Small, and Testable:
- Independent: It should convey a complete message and be independent of other user stories.
- Negotiable: It shouldn’t be final. It should be malleable and allow us to add modifications and details as the development process continues.
- Valuable: It must provide a tangible value to the customer.
- Estimable: It should help prioritize the users, and development times must be of a rational length that adapts to the project. If it’s too big or too small, it can damage the value of your product.
- Small: It must be short, concise, simple, clear, and to the point.
- Testable: It has to be easily testable within the development process.
Hopefully, by now, you have some clarity on what makes a good story, so let’s dive into our guidelines of how to write them.
1. Users Come First
User stories are about the users and the value your business can provide to them and solve their problems. Your user story must emphasize how the user will benefit from using the product and how the product will help the user overcome his or her issues. You should write your user stories using the user’s perspective and in the first person. Hence you should be placing yourself inside your user’s shoes beforehand. Furthermore, if you put your users first when writing your user stories, you’re helping our developers capture specific functionalities, such as making an appointment or performing a transaction.
2. Start with Epics
As we stated earlier, epics are big, coarse, and broad stories. An epic describes large pieces of functionality and provides a big organizational picture of the product. They are a helpful starting point to establish hierarchy and line out high-level goals instead of detailed solutions. As time passes and the development process continues, epics break down into more specific features and user stories.
Here’s an example to help clarify:
Epic: Perform online transactions.
User stories:
- As a banking customer, I want to pay my bills using an app to avoid long lines at the bank’s branch.
- As a banking customer, I want to make online purchases without entering my payment information every time to easily and swiftly buy goods.
You can break your epics into as many smaller, detailed stories as you need until you feel they are ready. Whichever number of user stories you think you need, the critical part is that they are clear, short, to-the-point, feasible, and testable.
3. Create User Personas
Although optional for you, we find that a great way to capture insights about your users is working with personas. As actors in your movie, personas are made-up characters based on actual, first-hand knowledge of your real users. You should note that the fact that personas are fictional doesn’t mean they’re entirely made up. Personas are tied to actual, tangible research of your target audience and reflect natural, current behaviors and patterns.
Your user personas are often named and have actual characteristics such as birthplace, age, socioeconomic status, real behaviors, likes, dislikes, and attitudes. They also add visibility to the main goal: the persona’s problem or the benefit they want to achieve by using your product. You may be wondering: Isn’t it enough with good ole’ user stories? Yes and no. See, user personas help us discover the correct stories. They help us determine which functionalities the product should have to meet the current goals of your existing users.
4. Add Acceptance Criteria
Acceptance criteria help us determine when the user stories are completed correctly and meet the user’s demands. You should write acceptance criteria as a set of statements that describe a precise pass or fail result. This way, they give us more details on functionality to help our developers determine when they fulfill a user story. They also help us decide if a user story works and if the product owner can accept it. Acceptance criteria also help us avoid ambiguity, unexpected results and prevent miscommunication regarding your demands and your user’s needs.
You can write your acceptance criteria using a checklist of scenario-oriented statements that illustrate each criterion achieving a result. Sounds complicated? Don’t worry, let’s look at some examples:
User Story: As a banking customer, I want to pay my credit card bill using an app to avoid the long lines at the bank’s branch.
Acceptance Criteria
- The user should start by accessing a login page where they can create a username and password.
- The user should see a screen asking them to enter their phone number to receive OTPs, notifications, and updates regarding their activity within the app.
- Upon entering their phone number, the system should send the user a confirmation with the OTP in a text message to successfully verify their account.
- The system then shows a “make payment” button.
- When the user clicks the “make payment” button, the system displays a list of payment options.
- When the user clicks on “pay credit card,” they should see a form to enter their credit card payment information.
- The user clicks “Submit,” and the system shows the user the option to choose from which account the app will withdraw the money for the payment.
- The user makes a selection, clicks the “confirm” button, and then gets a pop-up with the confirmation of the transaction.
As you can see, acceptance criteria are easy to write and don’t require technical knowledge, so you can quickly jot them out. With your list of acceptance criteria, we can capture all the needs, issues, and situations before starting our development process. They can help you, and our team communicate better and reach a consensus on and agree on what the product should be and do.
Wrapping Up
We hope that we’ve managed to convey the main concepts and importance of writing your user stories by now. These user stories help you articulate what your users will get from your product and can aid us in determining what features to develop, nothing more, nothing less. It places the focus on designing and developing for real user value instead of just coding to deliver. This way, your product will be on point, and your budget will thank you and us!
At Foonkie, we operate under the premise that your success is our success. We want your customers to be happy and satisfied with your product, and we want to create a durable tool for your business to thrive. All the aspects mentioned in this guide have that purpose in mind. We would love it if, after reading this guide, you’re excited and motivated to start your journey into writing user stories; they are, in fact, the first step towards a successful, long life for your product.
If you need any additional information or have questions about user stories or anything else, we’re just an e-mail away!