Writing User Stories and Grooming the Backlog
Focus on what can be done rather than be frustrated by what can’t be done.
—Ken Schwaber
The key drivers of work within an agile process are the user stories, which are collected from the customers, stored in the backlog, and built by the team. User stories are essentially requirements that are written from the perspective of the user of the product. The backlog is essentially a requirements list that is continuously groomed to understand priority and gain clarity. As a readiness activity within the RICH model, you need to consider the user story language construct you plan to use to help with consistency and comprehension, where you plan to store the Product Backlog for easy access and sorting, and how frequently you plan to groom the backlog.
Hierarchy of Requirements within an Agile Context
User stories are a form of requirements. The challenge with the word requirement is that it may indicate requirements at many levels and sizes, such as user requirements, technical requirements, and business objectives. Because of this possibility for confusion, you need to discriminate where any particular requirement belongs by virtue of its scope and size in a hierarchy of requirement types: themes, epics, user stories, and tasks.
Figure 18-1. Hierarchy of requirement types within an Agile context
Themes are top-level objectives that may span multiple releases and products. Themes should be decomposed into epics that can be applied to a specific product or release. Themes can be used by a solution or product to drive strategic alignment and communicate a clear direction. Examples are:
- Reduce the number of clicks to get to our user functionality within our products and services.
- Improve traffic to the website.
- Apply single sign-on capability to all company products.
Epics are the parent of multiple user stories and are roughly equivalent to a feature or very large story that encapsulates a large piece of functionality. Epics are written by the Product Owner. Epics are helpful when creating a product vision for a release. They should be decomposed into user stories before being introduced into a Sprint. Examples of epics are:
- Administrators can manage users.
- Customer can purchase a ticket.
User stories are equivalent to a business or user requirement and are collected and written by the Product Owner. Stories provide user functionality that represents value to the customer. A user story should be able to be built within a Sprint or, ideally, within half a Sprint. The next section treats user stories at length.
Tasks are the children of user stories and are equivalent to an incremental decomposition of the user story that is defined by the Agile Team. The intent of tasks is to allow the team to incrementally build and test the story so that not all testing occurs at the end. Avoid decomposing stories into stand-alone design, develop, and test tasks, which emphasize a mini-waterfall approach. When a team breaks user stories into tasks, it gains further clarification of the scope of work that needs to be done. For example, a user story that builds a search function can be decomposed into:
- Create static web page.
- Build simple search.
- Add advanced search capabilities.
There are other types of work items that should be captured in the backlog. XP introduces the spike solution, which provides a focus on solving a challenging technical, architectural, or design problem. Sometimes known as a research spike, this work may seek the answer to a critical business or technical issue. Two examples of research spikes are “What database solution will the team use?” and “What is the product direction in applying forums?” The answers serve to support subsequent epics and user stories.
User Stories
Within an Agile context, user stories are the primary currency used to determine what needs to be built by the team that represents customer value. User stories describe functionality that will be valuable to a user or purchaser of a system (persona). User stories are the primary topic discussed in Sprint Planning. The intent of a user story isn’t to specify every detail of the need but to provide enough detail to start a healthy conversation about the story to help flesh out the details.
Agile Pit Stop The user story is the primary requirement building block for specifying the functionality that needs to be built within a Sprint.
The Product Owner is responsible for eliciting user stories from customersand stakeholders. Many others, however, may contribute stories to the Product Owner, including the Agile Team, sales, and marketing. The Product Owner collects and adds the user stories into the Product Backlog. Those user stories that are rank-ordered highest within the backlog get selected and built within a Sprint. The attempt is to build user story functionality within a Sprint time-box.
Canonical Form
There are many ways to write a user story. A canonical form is an example of a requirements language construct that is geared toward Agile. This brief statement expresses a user story as who wants something, what they want from a system, and why. The canonical form transcends processes and methodology and works just as well for waterfall as it does for Agile. There are three key elements of a user story in canonical form: the persona, the action, and the business benefit.
- The persona represents a particular user of the system, as discussed in Chapter 17. Examples of personas include a buyer who must use the product to purchase items, a power user who uses the product to create quantitative reports, or an administrator who uses the system to manage users and install the most recent patch upgrades.
- The action represents what the persona would like to do with the product.
- The business benefit provides the value that is gained for the persona. It provides context for the action and helps with testing factors. If I said, “As a user, I can create an account” and leave the business benefit empty, why do you think the user wants an account? The answer can lead you to build very different things if you don’t know. If the answer is, “to become a member of the site,” you might build a MyPage. If the answer is, “to purchase concert tickets,” you might build an order entry system.
Canonical Form Construct and Examples
When establishing a list of user stories, it is strongly recommended to establish a user story language construct that helps you consistently document the stories. The language construct for a user story in canonical form looks like this:
As a <persona>, I want to <action> so that <business benefit>.
The following are examples of user stories in canonical form:
- As a user, I want to create an account so that I can become a member of the site.
- As a learner, I want to set up my profile to include my photo, so that my distributed team members know what I look like.
- As a prospective buyer, I want to search on homes so that I know what properties are available in my price range.
The Product Owner should be trained in writing user stories in the canonical form or whatever form is used to articulate requirements. The Agile Team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form. The Product Owner may also want to train stakeholders and customers on how to provide their needs in canonical form for consistency and clarity.
Acceptance Criteria and Other Attributes
The acceptance criteria are an important attribute of a user story. Each user story should have its own unique set of acceptance criteria. Acceptance criteria answer the question, “How will I know when I’m done with the story?” They do this by providing functional and nonfunctional information that helps set boundaries for the work and establishes pass/fail criteria for testers to establish the test cases that are used to test a user story.
Acceptance criteria spell out what the Product Owner expects and what the team needs to accomplish. Ideally, these criteria are provided by the customer at the time they articulate the user story. But they are usually written by the Product Owner acting as the voice of the customer. If the Product Owner is having problems writing effective acceptance criteria, a good resource is the QA team. QA testers can draw from their experience to help the PO.
To write effective acceptance criteria, state the intention, not the solution. In other words, state the “what” not the “how.” For example, it is better to write “The user can choose an account” rather than “The user can select the account from a drop-down menu.” You want the acceptance criteria to be independent of implementation details.
As an example, if the user story is, “As a user, I want to create an account so that I can become a member of the site,” then the acceptance criteria for a user story might include:
- User is presented with an account creation option.
- User must enter an email address and a password.
- The email address must be in a valid format.
- The password must follow the security policy.
- Provide user account confirmation within 5 seconds.
- User lands on the home page after creating the account.
A user story is complemented by several attributes besides the acceptance criteria. Figure 18-2 illustrates a user story card with helpful attributes. These attributes help you understand the scope, ownership, and progress of the story. Each user story should include the following attributes:
- Description: a place to add details and decisions.
- Size: a place to include the story point number (see Chapter 19).
- Tasks: decomposition of the user story into bits of work that represent an incremental build of functionality. They may be nested within a story or linked to the story.
- Owners: members of the team working on the story. There should be at least one developer and one QA tester.
- State: the status of the work such as open, in progress, resolved, verified, or done.
Figure 18-2. User story with attributes to provide a holistic view of the work
Product Backlog
A Product Backlog is a repository for user stories and other Product Backlog Items (PBIs) such as tasks, epics, and themes. The Product Backlog is the singular place to store all PBIs related to the product. Most Product Backlogs are either a form of document or in an agile planning product that offers automation to manage PBIs.
The Product Backlog is owned and managed by the Product Owner. Others may contribute to the backlog, but the Product Owner controls the prioritization and rank order of the work. The Product Backlog should be readily available to the Scrum Team to view and update, particularly the tasks associated with the user stories.
Agile Pit Stop Anyone associated with the product may contribute stories to the backlog. However, only the Product Owner can specify priority or rank order.
The key attributes of the Product Backlog are the priority and rank order (see Figure 18-3). These fields help sort the user stories toward the order of the work. Within an Agile context, the Product Owner and team gain details on the highest priority items, seeking to gain clarity, decomposing epics to user stories and user stories into tasks, and looking for dependencies among stories.
Figure 18-3. Hierarchy of the Product Backlog: highest priority items at the top where Sprint work is occurring
In a traditional waterfall world, the combination of the project plan and the requirements list drives the work. In an Agile world, the Product Backlog drives the work for a team.
Forms of Backlogs
The Product Backlog can be represented in various ways. In its fullest form, it is the location for the whole list of backlog items. There are other forms of backlog. They are the Sprint Backlog and Team Backlog.
The Sprint Backlog represents a subset of user stories that are prioritized and rank ordered. Those stories that are highest priority and fit the team velocity or amount of work a team can complete within a Sprint period become the Sprint Backlog. There is a unique Sprint Backlog for each Sprint. The items within it come from the Product Backlog and are identified and added during Sprint Planning. The Sprint Backlog forms the backbone of the work within a Sprint. All stories and tasks within the Sprint are recorded within the Sprint Backlog.
The Team Backlog is beneficial when you have multiple Scrum Teams building a product together. The Team Backlog represents a view of the work that is geared toward a particular Scrum Team. During grooming and Sprint Planning, the Scrum Team reviews their prioritized team backlog. From the team backlog, the team can establish a Sprint Backlog of those high-priority stories that the team will work on within a Sprint.
Attributes of a Backlog
A healthy backlog includes attributes that can be associated with the PBIs, such as user stories. It will include the attributes that are associated with a user story, such as a description, size, acceptance criteria, tasks, owner, and progress. In addition, because it is a large list, there are additional attributes that should be included to help you sort the requirements. These attributes include:
- PBI types: a way to differentiate between work types such as epic, theme, user stories, tasks, and bugs.
- ID: a way to provide a unique identifier for each PBI.
- Source: the origin of the PBI, such as customer or stakeholder.
- Priority: a way to differentiate the importance of the PBI, often written as high/medium/low, or 1/2/3/4, or must/should/could/would.
- Dependencies: a way to indicate when a PBI is dependent on other PBIs or external functions.
- Sprint: the Sprint within which the PBI is built.
- Comments: a place to provide additional notes.
The primary purpose of grooming is to prioritize the backlog so that when you initiate Sprint Planning, you have the stories ready for further refinement, sizing, adding to the Sprint, and gaining commitment to the work that is involved. Grooming may also include ensuring that the user story is in canonical format, details of the story are understood, dependencies are included, and acceptance criteria have been added or clarified. The better you groom the higher priority items within the backlog, the easier and shorter the Sprint Planning event will be.
Agile Pit Stop The key focus in backlog grooming is to prioritize and rank order the user stories, and then gain more details of those higher priority stories.
The PO is primarily responsible for grooming the backlog. The PO may also invite the full Scrum Team or a select few, such as the lead developer and lead QA team member. There is a great benefit for the PO to invite the Scrum Team. Most important, Scrum Team can ask the PO tough questions regarding specific information and acceptance criteria to gain relevant detail about the story.
Grooming should occur at several different times in your release life cycle: before and during Sprint 0, during Agile Release Planning, during Sprint Planning, and periodically throughout the release.
Before and during Sprint 0
Prior to the project starting, in between one project release and the next, or as a carry-over from the previous release, grooming should start or continue. At the start of any release, grooming should be driven by the PO and include input from the technical leads. If a Sprint 0 exists in the beginning of the project, consider a grooming event at least twice a week of about two hours or more throughout this Sprint.
The purpose of this early grooming is to start or continue collecting user stories to build the Product Backlog. In addition, grooming early helps the team gain an understanding of the work ahead, establishes priority, and helps discover dependencies, risks, and issues early.
Agile Release Planning
If the team applies the Agile Release Planning event toward the beginning of the project, grooming the higher priority stories helps the team appreciate the breadth of work ahead with the understanding that priorities may get adjusted and new user stories may be added (see Chapter 15).
The PO leads the team through the higher priority user stories one by one to accumulate more detail about backlog items; identify additional dependencies, risks, and issues; and potentially “T-shirt size” the stories (small, medium, and large). Ultimately this helps the team gain confidence of the work ahead.
Sprint Planning
The grooming that occurs within Sprint Planning focuses on gaining enough understanding of the user stories to build the functionality within a Sprint. This grooming will include gaining detail about the story, discussing design aspects, decomposing the story into tasks, and sizing the story. If the highest priority user stories are well groomed coming into Sprint Planning, then this event may be shorter than usual.
The grooming within Sprint Planning is performed by the PO and the team. The team should leave the Sprint Planning event with confidence in their knowledge of the user stories that are now part of the sprint backlog.
Periodically throughout the Release
After a release gets started, new user stories may continue to come in or, if there is an abundance of user stories in the backlog, reprioritization will occur. In both cases, those higher priority user stories should be groomed to better understand the potential work ahead. The advantage of having the Product Backlog groomed is that it can avoid disrupting a team’s progress if stories are poorly written or not understood.
With that in mind, at regular intervals throughout the Sprint, the PO continues backlog grooming, focusing on the new high-priority stories from customers and includes the team in fleshing out the details of those stories that are candidates for the next Sprint Planning event. The interval within a Sprint can vary depending on the rate of new stories coming into the backlog that are high priority and amount of existing high-priority stories that have not been groomed. As an example, this may occur twice a week, once a Sprint, or somewhere in between. The amount of time may vary from Sprint to Sprint.
The initial grooming of the backlog may occur at the Product Owner Scrum of Scrums if there are multiple teams that make up the release. This gives the PO a chance to discuss prioritization of the work with the other POs before discussing the high-priority stories with their team.
What Is Your Story?
User stories form the backbone of the work on your team. It is important that you consider a requirements language construct such as the canonical form. Including the persona or whom the functionality should be built for helps you understand the point of view of the persona. Including the action helps us understand what is being built. The business benefit provides the value gains and also helps you understand the functionality being built. These elements provide clarity for the team to build what the customer wants.
The Product Backlog provides a single place to store the user stories and other PBIs. It is important to think through whether you want to manually manage the backlog items within a document or in an agile planning product that offers automation to manage PBIs. Finally, ensure there is periodic grooming so you have a prioritized backlog in which the highest priority items have more details. This helps provide a broad view of the work ahead and easier Sprint Planning events. Thinking of these areas early and then sharing them with the team helps provide a framework for collecting, storing, prioritizing, sorting, and better understanding customer needs.