A user story is much more than a written artifact; it is a promise for a continued requirements conversation.
—Mario Moreira
I was tempted to entitle this chapter “Writing User Stories.” The reason I decided against it is the work of creating user stories entails much more than just writing. It requires collaboration among the product owner, team, customers, and others; it involves communicating the business meaning behind the story; and it emphasizes how the user story is much more than a written artifact. It is, instead, a promise for a continued conversation.
The Promise for a Conversation
A user story is a piece of user functionality that, when built, can be demonstrated and exercised. A user story has a before-and-after life. Similar to the temporal concept of AD (Anno Domini) and BCE (Before Common Era), the user story has an AD and a BCE. The BCE refers to the journey the idea or problem takes to get to the written user story, and the AD refers to the journey it takes to evolve into a piece of working product or service. In both cases, that journey should be a collaborative one that includes customer feedback. The earlier chapters in this book discussed in detail the collaborative nature of getting from an idea to user story.
Once the user stories and epics have been identified from the increment of story mapping or other practices that decompose ideas, it is time to write down the user stories. This continues the collaborative process of understanding the user story now that it is written, ergo the saying that the user story or requirement is a promise for a continued conversation.
The concept of the promise for a conversation is to move you away from “throwing the requirement over the wall” since the real value of understanding user stories is in the collaborative conversation along the way. “Throwing over the wall” refers to a practice where one group writes requirements that, when completed, are thrown over the wall to a group that has to build those requirements with little or no discussion, as illustrated in Figure 18-1.
Figure 18-1. “Over the wall” approach to requirements
A more robust approach is to have those who build the requirements be involved in the decomposition and grooming process to collaboratively flesh out the requirements in a collaborative manner, as illustrated in Figure 18-2. This is a mindset shift that recognizes that first-hand and shared information benefits the team with an outcome that is more aligned with customer value. Having team members involved in story mapping or the practice of decomposing ideas provides the team with insight into the customer experience and how you got to a thin-slice, end-to-end flow of the idea.
Figure 18-2. Collaborative conversational approach to requirements
Once the epics and user stories are visible from the first increment of story mapping, further refinement of epics and user stories can occur, as discussed in Chapter 17. This should continue through sprint planning or the next level of planning to better understand the work ahead. The collaborative process utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement to better shape a working solution based on the customer needs.
Collaboratively Engaging the Team
In an Agile world, writing down requirements provides a focal point where you can have collaborative conversations between the business and engineering sides. Whether this is between the PO and team or the customer and tester, the importance is that a shared understanding begins and continues. This discussion initiates the learning between the business and engineering sides where the engineering side better understands the customer value of the requirement and the business side better understands the options that can suit the customer needs.
Agile Pit Stop
The collaborative conversation includes internal people who bring the idea to fruition and external people who provide feedback to move in the direction of customer feedback.
The collaborative conversation goes beyond those internal to the enterprise. As discussed in Chapter 14, the customers and their feedback loops add to the collaboration. The internal focus brings the idea to fruition with healthy conversations to understand the customer needs. The external focus involves customers to gain their important feedback to determine if you are moving in the direction of customer value.
There are debates as to how many team members should be involved in story mapping or grooming user stories. My answer has always been all of them. For grooming user stories, this is the team. Having the whole team collaborate through the process eliminates the need of sharing second-hand information. For story mapping, the caveat is that you may do it in stages if there are more than ten people involved. The reason is to keep it active and engaging while allowing everyone to participate. For grooming and sprint planning, having the whole team collaborate ensures a greater understanding and applies the brainpower of everyone.
Top Branches of the Requirements Tree
User stories are a form of requirements. The challenge with the word requirements is that it may indicate requirements at many levels and sizes, such as user requirements, technical requirements, and business objectives. Because of the possibility for confusion, you need to be aware of your requirements tree discussed in Chapter 15. You need to determine where any particular requirement belongs by virtue of its scope and size in a hierarchy of requirements. Figure 18-3 illustrates user stories that live in a requirements tree that starts with corporate strategy and then has the levels of idea, increment, epic, user story, and task.
Figure 18-3. Top branches of a requirements tree
Since this chapter of the book continues the journey of the idea now being decomposed to user stories, a more detailed definition of epic, user story, and task as they relate to building new ideas follows.
An epic is the parent of multiple user stories and is roughly equivalent to a function, feature, or very large user story that encapsulates a large piece of functionality. Epics are typically written by the PO but may be contributed by other stakeholders or may result from a story mapping or other decomposition session. They should be decomposed into user stories before being introduced into a sprint.
A user story is the equivalent of a business or user requirement and is collected and managed by the PO. Stories provide user functionality that represents value to the customer. It should be non-compound and have one persona. A user story should be able to be built within a sprint. The next section discusses user stories at length.
A task is the child of a user story—a very small unit of work—and is equivalent to an incremental decomposition of the user story that the team defines. 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. Instead, tasks of a user story should incrementally build upon each other. For example, a user story that builds a search function (for instance: As a user, I want to search available mortgage options so I can determine which will be the least expensive) can be decomposed into the following:
Create a static Web page to hold my results
Build a simple search with available mortgage companies
Add advanced search capabilities with interest rate options
There are other types of work items that should be captured in the backlog. Extreme programming introduced the spike solution, which provides a focus on solving a challenging technical, architectural, or design problem. 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 customer and user (in other words, persona). User stories are the primary topic discussed in grooming and sprint planning. The intent of a user story isn’t to specify every detail of the need but to provide enough business and technical detail to have a healthy and collaborative conversation about the story.
Agile Pit Stop
The user story is the basic building block for a piece of functionality that needs to be built. It is the primary currency for the team to understand customer value.
The product owner is responsible for eliciting user stories from customers and stakeholders and identifying them in decomposition exercises such as story mapping. Many others, however, may contribute user stories to the PO, including the team and the sales and marketing departments. The PO collects and adds user stories into the backlog. Those user stories that are rank-ordered highest within the backlog get selected and built within a sprint or are the next to be pulled. The attempt is to build user story functionality within a sprint or approximately a week time box.
User Story Canonical Form
There are many ways to write a user story. The canonical form is one example of a requirements language construct that is geared toward Agile and customer value. This brief statement expresses a user story as who wants something, what that person wants, and why he or she wants it. The canonical form transcends process and works just as well for any methodology or process. 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, as discussed in Chapter 14. Examples include Erin the Senior Citizen, who uses basic user interface functionality for straightforward tasks; Sunny the Gen X-er, who needs more complex interface functionality for sophisticated banking tasks; and David the Gen Y-er, who is technically savvy and has simple banking needs.
Agile Pit Stop
There are three key elements of a user story in canonical form: the persona (who), the action (what is wanted), and the business benefit (why it is wanted).
The action represents what the personas would like to do with the product. This will include an outcome they are looking to achieve (for example, create an account) and may include a receiving entity (for instance, get a copy of my statement to read on my mobile phone).
The business benefit indicates the value that is gained for the persona. It provides context for the action and helps with testing scenarios. If I said, “As a user, I can create an account” and leave the business benefit empty, why would you think the user wants an account? The answer can lead you to build very different things. If the answer is “to become a member of the site,” you might build a MyPage. If the answer is “to make stock trades,” you might build a trading application.
When establishing a list of user stories, it is strongly recommended to establish a user story language construct like the canonical form that helps you consistently document the stories, as shown in Figure 18-4.
Figure 18-4. Agile canonical form
The following are examples of user stories in canonical form:
As Erin the Senior Citizen, I want to create an account so that I can become a member of the site.
As Sunny the Gen X-er, I want to set up my profile to include my photo so that my distributed team members know what I look like.
As David the Gen Y-er, I want to search homes so that I know what properties are available in my price range.
The product owner should be educated in writing user stories in the canonical form or whatever form is chosen to articulate user stories. The team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form to better determine the business need. The PO may also want to educate stakeholders and customers on how to provide their needs in canonical form for consistency and clarity.
It can be very easy to fall in the erroneous habit of writing long user stories. This is often because you want to add more detail to make the user story more meaningful. A better alternative is to write the additional detail into the body or comment section of the user story, depending on what tool you use to capture the user story. For example, it may be as simple as a note card or as sophisticated as a vendor backlog management tool.
Acceptance Criteria for a User Story
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.
Ideally, customers provide these criteria when they articulate the user story, but the PO usually writes the criteria, acting as the voice of the customer. If the PO is having problems writing acceptance criteria, team up with QA testers who can draw from their experience to help the PO.
Agile Pit Stop
To write effective acceptance criteria, state the intention, not the solution. In other words, state the “what,” not the “how. The team will figure out the how.
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.” The acceptance criteria are independent of implementation details. If the user story is “As Erin the Senior Citizen, I want to create an account so that I can become a member of the site,” then the acceptance criteria for a user story may include the following:
User is presented with an account creation option.
User must enter an e-mail address and a password.
The password must follow the security policy.
Provide user account confirmation within five seconds.
User lands on the home page after creating the account.
Other Attributes of a User Story
A user story is complemented by several attributes besides the acceptance criteria. These attributes help you describe the scope, ownership, and progress of the story, as illustrated in the story card in Figure 18-5. They may include the following:
Comments: any decisions or details that have an impact on the “how” to build it based on grooming and planning discussions.
Size: a place to include the size, typically in story points.
Tasks: decomposition of the user story into bits of work that represent an incremental build of functionality. They may be nested in a story or linked as individual children records to the user 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, and done.
Figure 18-5. Holistic view of a user story in story card form
Do User Stories Promote Conversation?
To get to a user story, the journey occurs both before the user story takes shape and after it is written, and it should be collaborative and evolutionary. The written user story is a promise for a conversation that helps the team both understand and shape the outcome to better meet customer value. Ensure you promote the conversation with the team and others.
User stories form the backbone of the work on your team. As you write user stories, 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 you understand what needs to be built. The business benefit helps you understand why the functionality is needed. These elements provide clarity for the team to build what the customer wants. The collaborative approach ensures that everyone on the team understands the customer needs so they can better build something the customer wants.