The quality and success of any project require excellent communication between the client and the development team. If clients are vague with descriptions of what they need, developers will have a hard time making a good product. More than anybody, software developers understand how important it is for a client to present their vision for a product clearly. Clients and teams working on the project write user stories to reduce the likelihood or even eliminate misunderstanding.
What are the user stories?
User stories allow anybody, no matter their level of expertise, to describe the functionality of their product using plain English without having to mention any technical details. The great thing about user stories is that they’re easy to write. They’re also essential when you’re starting a development project. Clients can write them on a small piece of paper, while developers usually put them on sticky notes or list them on a whiteboard.
User stories are an excellent way for the development team to brainstorm ideas and decide how a certain software product should look like. They allow clients to get the message of their vision across without having to worry about how it will be done.
Although some people may approach developers with a detailed list of requirements that perfectly describe the functionality of a product, most clients won’t have the technical knowledge to do this. User stories examples were created for those who perhaps don’t know how their software product should work but have a clear understanding of what their customers want.
In most cases, clients will write the majority of the user stories at the beginning of the project. As time passes and developers start working on it, they’ll take over the writing as a way to communicate and build on each other’s ideas. The user story itself is a tool used to spark a conversation between the team members who try to come up with ideas on how to reach a specific goal.
How to write user stories?
There is a simple equation that you can use to write a user story:
As a <type of user>, I want to <be able to do something> so that <some reason>.
As you can see, the format of a user story is very simple and doesn’t leave room for detail. However, this is exactly why it is used. User stories usually consist of 10-15 words, in which you can clearly describe the essence of your product and what you’re trying to accomplish with it.
The first part of the equation describes who the user of your product will be. The second part should clarify the feature you’re building. Meanwhile, the final part should describe exactly why you’re making the feature as well as why you think the customer will want to use it.
Bill Wake, one of the leading specialists in agile software development, created a set of criteria for user stories commonly known as INVEST. As a frequent contributor, he often tells students that following this set of criteria is essential for creating a good user story. The acronym INVEST stands for:
- Independent – One user story shouldn’t have any inherent dependency on another.
- Negotiable – User stories should always be used to start a discussion between developers, not to define a fixed workflow.
- Valuable – Each user story needs to be of value to the customer.
- Estimable – You should be able to determine how much time you’ll need to develop each user story.
- Small – A user story needs to be small enough so that it can be finished in as little time as possible.
- Testable – A user story needs to have the necessary information to make testing realizable.
Now, you might be thinking about why you would even need writing user stories if you could just describe the features you want your product to have. However, know that stories encourage developers to collaborate and brainstorm to come up with the most creative ways to build your product.
But to ensure that the development team understands the true value of your user story, you should set certain acceptance criteria goals. You’ll learn more about that in a minute after you go through some of the most notable practices for creating stories.
Best practices for writing user stories
Writing a user story template is so easy that anyone could do it. However, it can be challenging to write an effective story. Here are some tips for you on how to write user stories, so they work best for your product.
1. Keep your focus on users
You should start writing user stories only after you determine exactly why people would want to use your product. It’s imperative that you know who your target audience is and why they would be interested in a particular feature before you create a story.
Research your competitors and what their customers say about them. It’s also a good idea to interview users and ask them what they would like to see in a new product or update. Doing this will help you identify every type of customer that will potentially use your product and ensure that they’re satisfied.
2. Refine your user stories
After you write a user story, it doesn’t necessarily mean that your job is done. You’ll still have to discuss it with the development team or other individuals involved in the project. Sometimes a discussion will lead to new ideas, which is when you should determine if there is anything you should change in your user story. Remember that this is a collaborative effort, so don’t be afraid to share any new suggestions to make your product better.
3. Use paper cards
One of the best ways to ensure you have a good brainstorming session with other people working on the project is for each person to work on an idea separately at first. Distribute paper cards among the team and encourage each member to write down an idea for a user story. After everyone is finished writing their ideas, compare them, and try to determine what the best story would be.
4. Make user stories visible
Making a good product requires you to come up with numerous different user stories. To keep track of everything that you and other team members wrote, you should make every user story visible. Write down everything that you came up with on sticky notes and place them on a whiteboard.
Divide them into three categories – stories that are awaiting approval, stories that you’re currently working on, and the ones that are done. If the people working on your project don’t share the same office, make sure they can easily find the stories on your server.
5. Use personas to create user stories
Examine your target group and identify the types of users that are likely to use your product. Create fictional characters based on your research to decide which user stories are good. All you need to create personas is to jot down some relevant characteristics and behaviors of your target audience. Divide them into as many categories as possible and try to determine what users in each group are looking for in a product.
What is acceptance criteria in Agile?
In Agile, acceptance Criteria (AC) is a term used to describe a set of predefined requirements that developers must meet in order to finish working on a particular user story. While the development team is tasked with executing the stories by following the predefined requirements, you will have to define what your acceptance criteria are. Keep in mind that every user story needs to have a unique set of criteria.
If you don’t write good acceptance criteria for user stories, it may yield some unpredictable results when the developers finish your product. It’s worth mentioning that the product owner doesn’t have to be the only one to write acceptance criteria; the development team can also work on them, especially when discussing how they’ll work on user stories.
You need to have clear acceptance criteria to ensure you end up with a product your users will be satisfied with. You can write AC in different formats. Although you have the complete freedom to create your own format, there are two common formats used for creating acceptance criteria. Since they have specific structures, it’s usually a good idea to use one of two common formats to make sure each user story is executed perfectly.
How to write acceptance criteria?
Your first option is to use a scenario-oriented format. There is a process in software engineering known as behavior-driven development. It describes a process that encourages communication and collaboration between business participants in a software project and the development team.
The scenario-oriented AC approach is inherited from behavior-driven development and is an excellent way to set guidelines on when developers should begin and end testing a certain feature. If you decide to go with the scenario-oriented AC format, you’ll have to use these statements:
- Scenario – In the first statement, you’ll have to write the name of the behavior that you’re describing.
- Given – The second statement refers to the beginning stage of the scenario.
- When – The third statement involves a particular action that you want the user to make.
- Then – This is used to describe the outcome of the third statement.
- And – You can use “And” to continue any statement except “Scenario.”
This can seem a bit confusing at first, but it’s actually quite simple. Here’s an example of how a scenario-oriented format would look like on an example:
- User story: As a credit cardholder, I want to receive a notification when I have less than $1,000 in my account after making a big deposit so that I don’t overspend.
- Scenario: Notification to prevent overspending
- Given: The user has opened a bank account
- And: The user has received a credit card
- When: The user has less than $1,000 after a bigger deposit
- Then: The system notifies the user of their balance
The second most common method of writing acceptance criteria is using the rule-oriented format. Depending on your product, it can sometimes be extremely hard or even impossible to use the scenario-oriented format. When you want to clearly convey your message on how the design or user experience of your product should be, it’s best to use the rule-oriented format.
All you have to do is come up with a set of rules on how your product should look like. The rule-oriented format is basically like writing a simple bullet list with all the features you want your product to have. By doing this, you’ll ensure that the development team understands your vision clearly.
Best practices for writing acceptance criteria
There are a few important reasons why you should write user story acceptance criteria. If you were only to provide developers with user stories, you might not end up getting the product you expected. Developers may interpret your user stories in different ways without AC, which may cause conflicting ideas and make collaboration harder.
It can be hard to understand how to actually create acceptance criteria if you never had the opportunity to do it before. In case you don’t have any acceptance criteria examples or any experience writing AC, make it your dissertation topic. This will give you the chance to become a master of agile development before you even get a job in this field, and it will look very impressive on your resume.
Know that there are many professional software developers who offer dissertations services and are open to collaborating with Ph.D. students on topics like acceptance criteria.
Without acceptance criteria, you’re basically enabling the development team to decide when a particular story can be marked done. To avoid these problems, you should always set acceptance criteria for your user stories. Here are some of the best practices for writing AC.
1. Avoid making acceptance criteria too narrow
Understand that developers need to use a lot of creativity in their work. If you make acceptance criteria too narrow, they might not be able to create good features for your product. Remember that AC should not be used to describe a final solution, but rather what your intent is. Allow the development team to execute the user story in different ways by leaving some wiggle room.
2. Make sure the acceptance criteria are testable
The goal of writing acceptance criteria is not to describe how you want a certain feature to be made. The sole purpose of AC is to describe exactly what you want to make. Therefore, you need to make sure the acceptance criteria are testable with a clear Yes/No result. This means that the results of the tests shouldn’t leave any room for interpretation.
3. Make the acceptance criteria concise
The whole point of writing acceptance criteria is to ensure the development team doesn’t misinterpret your requests. With that being said, it’s imperative to make your AC concise. Whenever you’re writing acceptance criteria, try to look at it from an objective standpoint and figure out whether the developers will understand what you’re saying.
The best way to avoid confusion is to simply use short sentences. Don’t use jargon or complex words that can be interpreted in different ways. Know that developers will find it easier to remember short statements. If you keep your AC concise, there’ll be less room for error.
4. Share your ideas
Before the development team starts working, you should first share your ideas with them. Go over everything together to make sure you’re on the same page. Developers should analyze your acceptance criteria and share their interpretations. If you feel the need to clarify something, do it right away to keep confusion to a minimum later on. In some cases, you may even come up with better acceptance criteria after talking to the development team.
Conclusion
Collaboration is extremely important in order for any project to be a success. Although it’s easy to communicate and share ideas with people in your field, it can be challenging to do this with someone with a completely different set of skills.
You may have a keen sense of business and have a good idea of what your users want, but if you don’t have the technical know-how, you’ll have a hard time explaining what you need. This is where user stories come in.
User stories are an excellent tool to work out the technical details of your product with a development team using plain English. Not only do they allow you to express exactly what you want your product to have, but they also encourage collaboration between developers and will likely help them create something better than you expected.
The whole idea behind writing a user story is to break down the desired feature of your product to its most basic elements. To ensure that the development team executes each user story perfectly, you’ll also need to come up with a set of predefined requirements commonly referred to as acceptance criteria.
There are two basic formats for writing acceptance criteria – scenario-oriented and rule-oriented. If you’re unable to use either of these formats for your user stories, you always have the option of making your own custom criteria.
Michael Gorman is a highly skilled freelance writer and proofreader from the UK with deep interests in technology, programming, and software development. He is among the top paper writers in the country and loves spending his free time working with students. Michael loves seeing young people unlock their full potential, which is why he frequently collaborates with them and provides them with assignment help.
