Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.
— Mike Cohn
When you choose an agile methodology for software requirement gathering as opposed to the “waterfall” approach, you are certain to use user stories to express business goals and plan and estimate project deadlines.
As a software development tool, they provide a good framework for collecting requirements and keeping up with new and emerging ones.
So in this guide, we will briefly talk about the things to know to be good at writing software specifications with user stories.
By the end of the guide, you should have the details on what user stories are, what makes a good user story, and how to write most types of user stories.
[Software] requirements are emergent…For any non-trivial project, it’s impossible to imagine the perfect design for something, see every detail, and foresee and account for every technical challenge or situation that might occur along the way…Requirements often get defined, refined, added to, and deleted throughout the course of the project, or at whatever point there is something to look at and review.
— PJ Srivastava
What User Stories Are
User stories are a way to capture and describe the desired functionality of a software product. They are a short and simple description of a feature from the perspective of the potential user and part of the agile approach to software development, planning, and requirement gathering process.
Source: Mike Cohn
They are also considered to be an effective approach to time-constrained projects and a great way to introduce agility to the software development process.
Historically user stories were written on index cards or sticky notes that are typically arranged on walls or tables and are used to facilitate discussion with team members and plan the project at its most basic level.
Why User Stories Are Important
User stories share some of the same characteristics of use cases and traditional requirements statements.
The reason they are so crucial to the software development process is their ability to help continually facilitate discussions regarding what needs to be worked on in a manner that promotes a shared understanding of the requirements.
Another advantage of user stories is how they help development teams avoid being bugged down with too many details on how the system should work too early in the software process.
This technique makes user stories perfect for time-constrained projects. Development teams are compelled to write some user stories to help get an overall feel for the system before plunging into further detail.
How To Write User Stories
Writing user stories requires that you follow this standard template popularized by Mike Cohn:
As a <user type>, I want <some goal> so that <some reason>.
In other words, each story should answer questions regarding:
- Who: Who’s benefiting from this specific feature?
- What: What are we doing?
- Why: Why are we doing it?
It can be helpful to think of user stories on two separate levels; high-level stories — like the ones in the image above, and low-level ones that add details to the high-level stories.
Source: Mike Cohn
In a typical agile team, a workshop is held at the start of a project to discuss and create high-level stories that fully describe the expected functionality of the product.
These high-level stories are then further decomposed into sub-stories that can be built over a single iteration in future workshops where new high-level stories may also be introduced to the product backlog by team members.
These workshops are also used to discuss and add supporting details to sub-stories such as wireframes, and test cases, and to define the conditions that a story has to meet to be considered complete.
These details are what allow for precise release planning and effort estimation.
What Makes A Good User Story?
A common mistake in requirements definition using user stories is defining a particular solution or implementation during the workshop for collecting high-level stories. This is a gotcha that should be consciously looked out for.
To help prevent such mistakes from creeping into your user story during the requirement writing process, here are the characteristics of a good user story that you can examine your stories against:
Independence: Is your story independent? A good user story should be independent — meaning it can be developed and tested in any order. This quality of a good user story promotes flexibility and allows for an incremental and iterative approach to project development.
Concise and of Single Focus: A good user story must represent only a small slice of functionality that can be built and delivered independently as a plugin. It should be concise in description, focused, and address a single user need.
Negotiable: User stories should not be overly detailed or prescriptive. It must leave sufficient room for negotiation between the development team and product stakeholders to refine the requirements.
Testable: A good user story must be clear and concise enough that it becomes sufficiently obvious how to define acceptance criteria or test cases that should be used to verify their completion.
Estimable: It should be possible for the development team to be able to estimate the effort required to implement functionality from a good user story.
Read Tips for Conducting Rigorous QA Tests
Final Thoughts
To conclude, user stories are an important part of agile projects, especially Scrum ones, and are considered to be the best and most popular form of product requirements gathering.
In this guide, we’ve seen that when a user story is chosen as a way to collect requirements, it can help teams have a shared understanding of the project, estimate build time, and respond to changing requirements.
Although nowadays user stories usually take the form of text in a Jira issue or Trello board, we have seen that the characteristics of what makes a good user story remain constant whether on sticky notes or Trello board and that it lays particular emphasis on collaboration, communication, and a focus on delivering value to users when defining one.
Looking for help building a product idea? Reach out to us through our software development garage service. We help businesses like yours build and deliver big product ideas. See our case studies for more.