What are “user stories”? A guide for effective project management

What is a User Story?

• A user story is an informal, natural-language description of a software system's features written from an end-user's or system user's perspective.

• It is a tool used in Agile software development to capture a description of a software feature from an end-user perspective.

• A user story describes the type of user, what they want, and why.

• It helps to create a simplified description of a requirement.

User stories are essentially business requirements presented in a structured format. To explain why such a task description is important, let’s use an example outside of the IT world.

Imagine you’re renovating your house and hiring a contractor to renovate the bedroom. The contractor receives the following instructions:

“We want to renovate the bedroom—replace the flooring and repaint the walls beige.”

You leave for a week-long vacation, return home, and meet the contractor to inspect the work, only to find a surprise.

The bill is three times higher than expected, and the results are not what you had envisioned.

Why?

It turned out that the expectations were not specified. The contractor ordered and installed vinyl flooring, which was several times more expensive than the laminate flooring you had in mind. The walls were smoothed because the contractor decided they were uneven, even though you didn’t mind. Additionally, the shade of beige was completely wrong, and the ceiling was painted white, despite your request for it to be colored.

Similar issues can arise in the IT world.

How could this have been avoided?

You should have defined specific requirements with the contractor before leaving for vacation. In IT, these requirements take the form and structure of a User Story.

Using such stories minimises the risk of misunderstandings, and specific functional requirements are documented. After completing the work, you can review the list point by point to verify whether the work has been done as expected.

This approach benefits both sides—the contractor knows what to do (and what not to do) and how they will be evaluated, while the client knows exactly what to expect.

What is a User Story for a Developer or Tester?

A User Story is a way of documenting a specific functionality from the end user's perspective, including the most critical information about the values the client seeks.

A User Story is a key element in software development, especially in Agile and Scrum methodologies. The concept dates back to the late 1990s when Kent Beck introduced a set of practices called Extreme Programming (XP).

User stories guide developers or testers on what to focus on within a given task. However, it’s common for developers to lose sight of the broader business context while working on a task, leading to unnecessary changes or adjustments unrelated to the requirements. In extreme cases, the work completed might be unnecessary (e.g., smoothing walls in the renovation example).

User stories anchor developers, helping them return to what is required in the specific task. They clarify what the tester will evaluate (and what they won’t). For instance, handling edge cases that might consume 80% of the development time at a particular project stage may not be necessary. Without clear specifications, developers might assume these cases need to be addressed.

User stories also guide testers. A reported “bug” might not be an error but a scenario that isn’t currently supported (because it doesn’t need to be). This avoids unnecessary disputes between testers and developers.

The Investment in User Stories

The downside of writing User Stories is the time required to create them. However, compared to the potential costs of not having such requirements, they can prove to be an excellent investment. Properly written User Stories help ensure clear communication, minimize misunderstandings, and save time and resources for all parties involved.

Benefits of User Stories

• User stories reduce the time spent writing exhaustive documentation by emphasizing customer-centric conversations.

• They allow teams to deliver quality software more quickly, which is what customers prefer.

• User stories clearly understand the desired functionality from the user’s perspective.

• They facilitate sensemaking and communication among stakeholders.

Writing User Stories

• Writing good user stories in Scrum requires understanding the basic user story template, focusing on the user or customer, and clearly defining the desired functionality.

• Remember that user stories follow a standard template: “As a <WHO>, I want <WHAT> so that <WHY>”.

• User stories should be written in a way that is easy to understand and concise.

User Story Examples

• One of the best ways to learn how to write a user story in Agile is to see examples.

• Below is an example user story or two: “As a user, I want to search for job postings so that I can find a job that matches my skills”.

• User story examples can help to illustrate the concept and provide a starting point for creating user stories.

Who Writes User Stories?

• Anyone can write user stories.

• It’s the product owner’s responsibility to make sure a product backlog of Agile user stories exists, but that doesn’t mean that the product owner is the one who writes them.

• Throughout a good Agile project, you should expect to have user stories written by each team member.

When Are User Stories Written?

• User stories are written throughout the Agile project.

• Usually, a story-writing workshop is held near the start of the Agile project. In this workshop, everyone on the team creates a product backlog that fully describes the functionality to be added throughout the project.

Organizing User Stories

• A user story map organizes user stories into a manageable model for systematically planning, understanding, and organizing the system's functionality.

• User stories can also be grouped into epics, themes, and initiatives for ontological, semantic, and organizational reasons.

Relationship to Epics, Themes, and Initiatives

• Epics and themes are used to group user stories. Epics are high-level groupings, and themes are stories, epics, or features that form a common semantic unit or goal.

• Initiatives are also referred to as programs in certain scaled Agile frameworks.

• User stories are often summarized in groups for ontological, semantic, and organizational reasons.

Acceptance Criteria

• Acceptance criteria define a user story's boundaries and confirm when a story is completed and working as intended.

• They are notes about what the story must do for the product owner to accept it as complete.

• Acceptance criteria can be written in various formats, such as bullet points, Given-When-Then, or points taken from original requirements.

Comparing with Use Cases

• A use case is a generalized description of interactions between the system and one or more actors.

• While user stories and use cases have similarities, they differ.

• User stories focus more on the user’s perspective and influence the system's functionality. In contrast, use cases focus more on the system’s behaviour and describe how it interacts with actors.

Non-Functional Requirements as User Stories

• How should Agile teams handle non-functional requirements, such as desired performance, security, or usability features when writing user stories?

• Non-functional requirements can be written as user stories but should focus on the user’s perspective and the desired functionality.

Lifecycle of a User Story

• In a broad sense, each user story has six main states throughout a software project: Pending, To-do, Discussing, Developing, Confirming, and Finished.

• User stories have a lifecycle, from creation to completion, with each stage having its own set of activities and deliverables.

Stages of a User Story

Pending: User stories are found through the communication between the user and the project team.

• To-do: Through a discussion between different stakeholders, the user stories to be addressed in the next few weeks are decided and put into a time box called a sprint.

• Discussing: When a user story is in the Discussing state, the end user communicates with the development team to confirm the requirements and define the acceptance criteria.

• Developing: After clarifying the requirements, the development team will design and implement the features to fulfil users’ requests.

• Confirming: Once the development team has implemented a user story, the end user will confirm the user story.

• Finished: Finally, the feature is confirmed to be finished, and the user story is considered Finished.

Conclusion

• User stories are powerful tools for Agile software development. They help us clearly understand the desired functionality from the user’s perspective.

• By following the user story template and writing user stories that are easy to understand and concise, teams can deliver quality software more quickly and effectively.

• User stories facilitate sensemaking and communication among stakeholders and provide a clear understanding of the desired functionality from the user’s perspective.