The basis of planning for agile software development is user stories. They are a critical element that enables frequent customer value delivery (Ref. Agile Manifesto). This article, the second in the series of Agile Planning, will discuss user stories in detail.
Table of Contents
What Are User Stories?
User stories are short, clear, and concise descriptions of what you want to achieve, why it’s essential, and its value to the business.
User stories are written in simple language. They provide natural language descriptions of the software requirements, but they don’t include any details about how it works. The development team adds such details later and breaks down the stories into implementable, actionable tasks.
Scrum teams use user stories as a framework for organizing tasks. For example, a user story is added to a sprint from the product backlog and then burned down. Kanban users pull user stories into their queue and run them through their process. This approach helps them improve their ability to estimate and plan.
User stories represent product and customers requirements focused on the outcome. They enable uncovering details about the need through conversations and planning and determining acceptance criteria for the feature it represents.
Agile teams represent user stories through cards. Though the user story cards are considered free form, teams use a variety of templates to describe the story. For example, one popular user story template represents the Who, What, and Why story. The sentence on the card would read something like this; “As a <type of user>, I want <functionality>, so that <derive specific business value>..”
The following can be one of the examples of user stories that represent reading this article;
“As an agile enthusiast, I want to understand more about user stories, so that I can optimally how we capture, discuss, execute and deliver customer value.”
While this template is most popular because of its simplicity and effectiveness, you are free to express the stories in any manner you see fit. However, a good user story would represent user persona and user goals to focus their activities on those outcomes.
Epics & Themes
Before we delve deeper into user stories, let us understand two more terms related to user stories. First, user stories are progressively elaborated. In the start, they may represent an extremely high-level requirement. Teams will break down such stories into smaller stories in the future, but not for immediate iteration. Such high-level user stories are known as Epics.
Then there are themes. There may be a situation when multiple user stories must be treated as a single unit because they represent a single logical functionality. Such a collection of related user stories is called a Theme.
Estimable User stories are neither too abstract nor too detailed. Remember, a user story must represent a single requirement completely. However, they do not contain exact tasks to develop the story. Instead, teams uncover the details about the story through conversations with customers. Acceptance tests, written for the stories, express the precise details of the story. The tests define the completion conditions for the user story and thus cover details. “INVEST” is the term that provides a guideline for defining good user stories.
Characteristics of Good User Stories
INVEST stands for Independent, Negotiable, Valuable to users or customers, Estimable, Small, and Testable. Let us examine the details of each of these characteristics one by one.
Independent
The dependencies of activities in traditional planning approaches create planning complexities and schedule risks. It also creates a cascading effect in one of the activities is delayed. User stories should represent a single, independent, self-contained requirement to avoid these complexities and risks.
A simple example would be stories representing a website’s login functionality. It would not be independent if you included requirements for login and forgotten password retrievals as a single story. However, if you break it up into two separate stories, one representing login requirements and another describing forgotten password retrieval requirements, you will get two independent user stories. In addition, you can now estimate, develop, and test separately without dependencies.
Negotiable
User stories are not contracts. They represent requirements, but details are not clear upfront. The team goes into exact information only when they get near the time when they want to implement the user story. This approach leaves options open for customers and the team to fine-tune them.
Conversations between teams and customers uncover the details. In this sense, user stories work as reminders to have conversations about requirements in the future.
Valuable
Sometimes, a user story represents the characteristics of a requirement or infrastructure details. Though they might be necessary to provide value to the user, their representation should be customer or user-centric, rather than developer-centric. So, instead of specifying architectural styles that support scalability, the user story should say that the system should be scalable to keep increasing users or features. Acceptance tests will represent the characteristics of such a story. In the above example, teams can specify the exact definition of scalability regarding the number of concurrent users in the test.
One thing to note here is that you should consider the value for both the end-users and the customers or the system owners. Specific requirements might not add value to users but may be valuable to the customer or the owner. Stories representing such requirements are perfectly valid. The idea should refrain from including task details or development-related details in user stories. One way to do that is to let the customer or product owner draft the story.
Estimable
Since the estimation for the time it will take to implement a user requirement in the form of working code will be done based on user stories, developers must estimate the size of the story to a fair extent. There might be three reasons for the story being difficult to estimate;
- It is too vague
- It is too large
- It does not offer sufficient details.
- The developers do not have enough domain knowledge to be able to judge the story size
- The developers do not have the technical expertise required for the story.Â
In case of vague user stories or a lack of domain knowledge, developers can better understand the exact details through additional conversations with customers. In addition, you can compensate for the lack of technical expertise through particular research tasks, which XP identifies as a spike. You may utilize the spike to work on the story to the extent that it provides just enough information to create the story’s estimate.
Small
The small refers to a user story that is not too big and small but sized appropriately for estimation. The size varies depending upon the team, capabilities, and technology. Stories that the development team is planning to develop soon should have more details. The stories to be taken up in future iterations can remain significant and be detailed later.
Testable
The last characteristic of a good user story is that it should be testable. Stories like the software should be easy to use and difficult to test, as there are no criteria to define ease. The successful passing of the test indicates that the work on the user story is complete.
Another aspect of testability characteristic is that teams should try to maximize automated testing. In adoptive change scenarios advocated by agile, things can go wrong with every code change. In the absence of automated tests, it would be a vast effort to conduct testing. Developing a testable user story with automated tests should be the team’s focus.
Splitting stories
There are several reasons why you would need to split a user story. First, the original story might be big enough to estimate and fit into a single iteration accurately. Epics usually represent multiple stories that the team would eventually split into smaller, more detailed individual stories.
Operational Boundaries
There are many ways to split a user story. One of the more straightforward ways would be to split the user stories based on operations. For example, divide a story such that a single story would represent each of CRUD or create, read, update, and delete operations. Or, in the case of a page that displays data in tabular format and search options to filter that data, the display and filter operations might be implemented using their individual stories.
Data Boundaries
Another way is to split the story based on the data boundaries. For example, in an online travel booking site, bookings for flights and hotels are often combined. But while developing, they can be treated as different stories, based on the data required for each story.
Common Foundational Boundaries
Standard functionalities might provide the foundation for functionalities built on top of that foundational layer. For example, other top-level user stories use security or error handling features. If a user story gets big because of the inclusion of such standard functions, it may be helpful to split them into different stories. First, you can develop only the top-level feature without the support of lower-level operations, and then, as part of the second story, the functions may be added.
Functional and Non-functional aspects
The splitting is also possible based on functional and non-functional aspects of the requirement represented by the story. For example, performance constraints for a user story mean the non-functional aspects of the requirements. Therefore, it is possible to build the functional elements first and then do the performance tuning as part of another, separate user story.
Mixed Priorities
When a story has a subset of requirements, there will be parts of different priorities—taking one of the earlier examples of displaying results of a search query in tabular format along with filter and ordering functionality for results. In this case, the filtering and ordering functionality may have a lower priority than displaying results. In such a case, the story can be split based on importance.
Tracer Bullet
It is better to have a few things out of many that you can develop completely to be production-ready, rather than having many things developed partially. For example, while splitting the stories, instead of first developing complete UI, then producing a whole middle tier, and so forth, it is better to have some part of functionality developed completely across all layers, UI, middle tier, and data. Tracer bullet represents this concept. This approach provides real value to the customer and reduces waste.
Combining Stories
It is not always about making the stories smaller. There might be defect corrections or small UI changes, too simple or too small to estimate. You should size stories appropriately to represent enough work based on the length of the iteration. For example, 1-3 days or work for a user story might be appropriate for a 1-week iteration. In cases where the stories are too small, you can combine them into a single unit. This way, multiple minor bug repairs can be treated as a single story. Using paper note cards, you can combine such stories by stapling them with a cover story to identify them as a single unit.
Why User Stories?
User stories are an excellent tool for keeping your team focused on what matters most – the customer! User stories, as part of the product backlog, help you understand all the work the agile team should do for the product, when the team should do it, who does it, why it needs to be done, and how long it takes.
Expressing product requirements as stories also helps a product owner or a product manager to gather concrete and actionable feedback, as they can trace the learning back to specific user actions. The acceptance criteria also help them ensure product quality as well as a mechanism to integrate such user feedback back to the product development.
User stories help teams collaborate by defining the end goal. They also drive creativity and critical thinking by forcing everyone to develop ideas to solve real problems.
User stories also help teams be motivated and ensure the efficiency and effectiveness of the deliveries, as the team can frequently see client problems getting solved.
