_edited_edited.png)
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer. The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. It helps to capture the value that a feature will bring to the user and is used in agile software development to capture the requirements of a product.
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 describes 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 many 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 of user stories 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 that 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 to write 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.
What purpose do User Stories serve from a project management perspective?
User stories can serve several purposes:
· They allow discovery and refinement of the user needs, in a way that both the team and the customer/users can understand. User stories lend themselves very flexibly to iterative and incremental clarification over time.
· They provide a way to manage and track the growth of the system, over time. From the stories and the backlog, we can see what capabilities are already working in the system, and which ones are coming up (and roughly when).
· They provide a way to discuss the way in which the system is created. They can also be used as the foundation for estimation, which is also iterative over time as the stories are being refined to smaller and clearer functionalities.
· They provide a way in which the different competencies within the team can discuss, coordinate, and integrate their work effectively and transparently.
For user stories to work, we do need a cross-functional team that can take the story from 0% to 100% without handovers between teams. That in turn requires that a story is a “vertical slice” (i.e., composing of all development activities and layers of structure required to make a given capability work). We also need to complete each story to “potentially shippable” technical quality, so that we don’t have to go back to old stories to finish them up later.
Personally, being very comfortable with the approach, I find them a powerful way to create an understanding of what makes sense to build, how to build it, and how to schedule the various capabilities over time. People who don’t have that level of comfort may not find them equally powerful, at least at first.
What is the importance of user stories in Agile?
User stories are not normally detailed. They should define the business problem to be solved, not how to solve it. A user story is a “placeholder for conversation”. It is expected that the developers will communicate directly with the users to better understand the need and to determine the most appropriate solution.
It is perfectly acceptable to add acceptance criteria to a user story and that is one way to add details, but those acceptance criteria should be in terms of the results that the user story must produce rather than details on how to implement it.
There are two parts to this question: accepting the story as ready for work and accepting the story as ready to release.
First, the dev team accepts the story as ready for work. The story begins in planning with the product owner. He/she explains the story in a “Discovery Session” with the team, together with the team they write any clarifications and the acceptance criteria—the “Definition of Done”. When resources allow, stories are pulled from “Ready” to “Working/In-progress” by the dev team.
Second, the product owner accepts the story as ready to release. The dev team says, “We’re done!” and demonstrate the story. The product owner checks all the acceptance criteria. When acceptance criteria have been met, the story is accepted by the product owner for release.
You can replace product owner with product manager in some scenarios. In some teams, product owner and product manager are the same, in others, they are separated.
A user story is a short statement of intent that describes something that the system should do for the user. The great thing about user stories is that you can break your work into a series of tasks. Working on them adds value to the project implementation process. A user story is a technique that is based on agile practices, including the principles of continuous delivery and direct communication with a user. Usually, in Agile, the product owner writes most user stories themselves at the beginning of the project. At this point, the development team discusses the requirements of each user story and related functionality.
Pros: It simplifies the requirements definition process and focuses on the business need rather than on what the solution to that business need might be. It’s a great way to streamline the requirements definition process and to structure the requirements into “bite-sized junks” that can be easily prioritized to work on incrementally.
Cons: It requires a collaborative relationship between the business users and the development team to further elaborate the definition of the requirements as the project is in progress. A popular saying is that “A user story is a placeholder for conversation”. This in turn also requires some sophistication on the part of the development team to be able to work directly and communicate directly with the business users rather than simply coding something from a well-defined spec.
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 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.
To conclude:
Collaboration is extremely important 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.