Every novice web developer has heard about Agile methodology, but not everyone knows what it is, why it is needed, and how to work with it.
This article will cover the latest practices of working with requirements relevant to the extremely dynamic world and Agile development approaches. If you’ve been searching the internet to find the answer to how to create user stories, you’ve come to the right place. We will introduce you to this seemingly complex topic and tell you all the peculiarities and nuances of writing a good user story.
What is a User Story?
User Story is a minimalistic, consistent format for expressing requirements that is easy to write, read, and evaluate. User stories have emerged as an embodiment of one of the principles of the Agile approach, which assumes continuous communication with the customer instead of carefully fixed requirements in the ToR or contract. The most common mistake of newcomers and even experienced programmers is that they think of user stories as requirements, but this is untrue. You can learn how to write a request for proposal for software development in our article to avoid confusing these two concepts.
The second point – why exactly “stories” and not “notes on a napkin”? The human brain is so organized that we perceive stories best. It is much easier to transmit and perceive a set of information in a story than in the form of isolated elements and information units. That is, compared to how requirements usually look in a ToR or specification – even if there is a structure, it is often difficult to capture and hold in your head as a complete picture.
What is the Difference Between Agile and Scrum User Stories?
When discussing software development, you can often hear terms like Agile and Scrum. What is the difference, and how do they generally relate to user stories?
- Agile is a set of principles for developing software through agile project management methods. Agile user stories are a tool that helps make project requirements more understandable to everyone. Agile stories induce the development team to focus on creating a valuable product for the customer while providing flexibility in changing priorities and requirements.
- Scrum is considered a more structured approach to implementing the Agile methodology. This is a framework that defines specific roles, events, and artifacts. Scrum user stories serve as the primary tool for creating an organized list of work needed to certainly create the required product. Scrum is characterized by a more formalized process for dealing with user stories, including their evaluation, prioritization, and scheduling within sprints.
Scrum and Agile are software development processes and methodologies that every novice and experienced developer should know about.
What is Epic Needed for?
If we talk about the epic and its meaning, you should imagine something big in front of you. For example, imagine that an epic is a brick house, and each brick in it is a story. In other words, it’s a big story that can’t be written at one time, so it’s divided into many parts. This makes epics fit into the principles of Agile (regular shipment of software ready for release, constant readiness for early launch, regular retrospectives).
Example of an epic: «As a customer, I want to be able to add items to my wishlist so I can go back and buy them later».
Benefits of Creating User Stories
Why do we need to write user stories at all? What are the benefits of writing user stories? These are questions that many people have. User stories are a quick way to record customer requirements without creating an extensive formalized document. As a consequence, it is much cheaper to update them in the future. That is why they are used in those projects where it is necessary to react rapidly to changes in requirements and conditions of software operation. Another value of writing effective user stories is that their aggregate helps to form an acceptance testing procedure. The client can utilize user stories to ensure the software is written correctly.
Apart from all this, user stories provide additional benefits to the testing department (QA):
- Help to make a test plan (organize it into stories).
- Each user story is analogous to a test scenario, where you can set test cases or checklists.
- Facilitate the formulation of test activities and constraints.
- Allow flexibility to change the test strategy and plan as requirements from the customer change.
- Simplify the calculation of test coverage metrics.
- Help shape tests for acceptance testing.
How to Write User Stories
The head of your department has given you an assignment to write a good user story when it will be useful in further development, and you need to learn how to write a user story in Agile. We will help you understand the whole process, telling you everything in simple words.
Who Writes User Stories?
The approach to identifying needs through user stories is called narrative collaboration. Participants (customers, managers, development team) describe the intended experience as a narrative, identify key elements, and capture them as atomic entities. The result is a line of cards that provide a coherent experience. It is possible to have several lines – for different persons.
Stages of Writing a User Story
How to write a user story? The 3R format (Role – Requirements – Reason) is considered to be the definition of a user story. User stories do not have a rigid format. This template was invented and used by guys from a little-known telecom company, Connextra, who presented it in 2001 at the XP conference in London. Here’s what that template looks like: “As [type of user], I want to [do this and that], so I can [get this benefit].” And it was so handy that it caught on and spread worldwide.
| Who | Stakeholder (user, customer, persona). |
| What | Specific task is to be accomplished or function to be provided. |
| Why | Provides an understanding of the value of the requirement. Highlights the alignment of the requirement with the overall vision and purpose of the product. |
The full formula by which user stories are written looks like this:
- <Acting party> — the user’s role in the system or status.
- <Situation/circumstance> — for example, paying for an order or registering a new user.
- <Action> — for example, take an order. Here lies the most insidious mistake. It is important to record not a specific action in the system («Click the accept button») but a request to satisfy a need («Confirm the paid order»). Do not drive yourself into the framework of a ready-made solution instead of searching for the best option for the existing requirements.
- <Expected result> — for example, send a kit order. Don’t skip this part, it keeps opinions unbiased among all participants.
If you know how to write good user stories, you should be sure to include the following at the end:
- Acceptance criteria. Do not confuse acceptance criteria with performance criteria. The former form the customer’s expectations of the work process details and answers the «how» question, while the latter answer the «what» question.
- Possible scenarios. The flow of a user story works when a story has multiple scenarios. And all must fulfill the acceptance criteria. Scenarios make it easier to write autotests on user stories and demonstrate the result to the customer.
- List of all the tasks that make up the realization of the above story. As practice shows, decomposition into functions is performed by each developer independently, coordinating the result with the team leader of this department.
This is how most user stories worldwide are written for a wide variety of tasks.
How to Write User Stories Behind «The INVEST Acronym Method»?
A person who first encounters user stories that need to be evaluated doesn’t know how to do it. To evaluate the quality of a story, there is a convenient mnemonic acronym INVEST, which was invented by American Bill Weick. This is what the structure of this method looks like
Independent
Ideally, each story can be implemented, tested, and deprecated and thus can exist without dependencies on other stories. Example:
- As an administrator, I can manage the withdrawal security rules for users.
- As a user, I can’t create a withdrawal request if it violates the withdrawal security rules.
Both stories are related. It is unclear how to test them and provide them to the product separately.
Negotiable
This attribute adds flexibility to the development team. We accept that we don’t have fixed requirements, as unforeseen changes are possible. We believe in the ability of the team and the business to compromise between functionality and release date. This increases the reliability of the product and builds trust between the parties.
Valuable
This is the most important attribute. It is responsible for ensuring that the story has any value for the time allotted to work on it. It is based on this attribute that all available user stories are prioritized. The higher the business value, the sooner the story will go into development.
Estimable
The predictability of the development team depends on this attribute. If we cannot evaluate a story approximately, it is not decomposed enough. Often, when discussing labor costs, it is possible to find some hidden moments in the story, which once again confirms the importance of this attribute and the process of preliminary evaluation.
Small
One of the key principles of lean manufacturing is that to increase throughput and deliver more value, you need to divide the volume of tasks by duration. The smaller the volume of each user story, the higher the throughput and speed of value delivery.
Testable
If the team knows how to test a story, then they understand how to implement it. Use the acceptance criteria agreed upon with the customer and write tests. To make it easier for the team and the customer to synchronize expectations on the results, avoid vague formulations such as “fast, beautiful, convenient, intuitive, etc.”. Such things are not testable because they are subjective.
At first glance, it may seem that it is all complicated and confusing, but it is not so at all. You just need to pay a little attention to each point (from I to T).
Acceptance Criteria
Another element that is often overlooked when using stories is Acceptance criteria, which are simple, concrete conditions to verify that a story is fulfilled. They also become the basis for acceptance tests. In this case, one criterion can become the basis for several tests, or, on the contrary, one test can cover several criteria at once.
Formation of acceptance criteria is the search for a balance between complete flexibility when there are no criteria (but then there is high uncertainty) and the situation when we have defined and described everything (and then the story is no longer Negotiable). Practice shows that the optimal point is not even in the middle but closer to the beginning of the scale. That is the minimum necessary set of criteria. Also, many criteria may indicate that the story is too large and should be divided into smaller ones.
Real Examples of Good User Stories
To back up all the knowledge of clever terms, it’s best to see what user stories look like in practice. We’ve collected good user story examples specifically for you:
- As a user, I want a contrasting app shortcut so I can find it faster on the screen.
- As a passive job seeker, I want to make my resume available to any interested employer so I don’t waste time sending it out.
- As a shopper, I want to use a shopping cart to inspect my selected items in one place.
- As a hair salon owner, I want to see photos of the hairstyles offered on the site to attract more customers.
- As a passenger, I want to see all available cabs in the app to choose the most favorable option.
- As a healthy eater, I want to see the product’s composition to monitor my health.
Wrapping Up
Practice shows that writing code is not the hardest part of product development. Most of the time, difficulty comes from identifying and understanding the true purpose of writing code. We hope we have helped you answer the question of how to write Agile user stories. The most important points to succeed in user story writing:
- When you formulate a story, describe the intent of what the system should do for the user.
- Focus on the value to users from your story rather than a structural or functional breakdown into tasks and technical components.
- Check the resulting stories for INVEST compliance.
- Work out the acceptance criteria for each story separately with the product owner.
- When you plan your implementation and create tasks, mentally “slice” user stories through so that users experience the value of your deliverables as early as possible.
- Check the wording of the stories, paying special attention to <action> and the presence of a need.
Binerals is known to many for its expertise in agile methodology and the quality of building user stories for any domain. You can avail the services of a dedicated software development team to speed up the development processes for your digital products. You will be pleasantly surprised at how well Binerals does its job in software development!
