Skip to main content

13.2 Writing Stories 🎯

note

This section includes an Activity 🎯

Learning objective

Agile software development helps teams be more adaptable. It does this by translating business requirements into actionable items—these are called epics or user stories.

Epics and user stories connect high-level roadmap ideas with concrete, executable tasks that can be timeboxed and tracked. These help teams adapt quickly and easily to changes. For instance, user research or technical limitations often cause implementation to differ from what the team originally planned. Highly detailed business requirements—like those you'd find in waterfall development—make it challenging to respond to these changes and all the ripple effects they have on other tasks. But in agile, epics and stories provide a fluid and actionable approach and prevent an endless cycle of complicated revisions to comprehensive documentation.

Rather than getting deep into implementation specifics that can be subject to change later, epics and stories function more like an outline. Epics represent a higher-level portion of work, and stories are the bullet points or breakdown of how you would address that larger portion of work. Epics don't go into interface design or implementation details; they focus on what the feature will enable a user to do. Then you work with your development team to determine how they will implement the feature.

In this checkpoint, you will learn more about these important agile concepts and practice how and when to use epics and stories.

By the end of this checkpoint, you should be able to do the following:

  • Explain how epics and stories facilitate communication with your development team
  • Translate high-level feature ideas into epics
  • Deconstruct epics into effective user stories



Epics​

At their most basic level, epics and stories function like elements of an outline. Rather than addressing implementation specifics that might change, epics and stories focus on the essential core tasks at the surface of the project.

Basically, epics are the higher-level portions of work, and the stories are the specific breakdown of tasks that show how the team will chip away at those larger portions of work. Epics don't deal with interface design or implementation details. They focus on what the feature will enable a user to do. Then, the development team determines how they will implement the feature.

Teams use epics to identify a body of work in many different contexts. For instance, launching large features may be a brand new initiative that requires a team to identify many epics to build out greenfields functionality—a term that refers to the process of building new features or products from scratch without the help of legacy features or existing architecture. But a team might need only a few epics if it were adding new functionality to a mature platform by building on existing features.

Epics are organizational buckets for the development team. They typically reflect how a business stakeholder, like a marketing or sales rep, might talk about the work being done. They're also big. Epics usually take several weeks or sprints for a team to complete.

But what actually qualifies as an epic? Here are some real-world examples of epics:

  • Integrate analytics into the marketing team's tool so they can better target their emails
  • Reduce the average load time of the home page to under two seconds
  • Enable users to sync their upcoming appointments with their iCal and Google Calendar
  • Allow clients to personalize the look and feel of their interface through admin settings

Epics don't have to be specific, but they must give a sense of what the outcome should be at the end of the development work. In fact, the right-size epic should be a little vague so that the team can explore as many solutions as possible. An easy way to imagine these is as the bullets presented to business stakeholders when you discuss your roadmap.

The video below by Mike Clayton provides a brief overview of how epics and user stories work in agile development.

Stories​

The real development work and planning begins when the team breaks down epics into stories. In this process, the product manager identifies the individual contextual components that will accomplish the goal of the epic. These are the stories. Stories are written as single sentences. Each story represents an individual item that delivers value to the users or business. Then, the team can flesh out the stories with whatever additional details are needed to complete them.

Consider this epic: "Allow clients to personalize the look and feel of their interface through admin settings." This epic might break down into the four stories below:

  • As a client user, I want to change the colors so that the app matches my company's branding.
  • As a client user, I want to change the layout of the home page with layout options so that I can get the information I need most often in one place.
  • When I get a new client, I want to change the logo on the landing page so I can make a good impression on those clients.
  • When my company has a new promotion, I want to make it the hero image on the landing page so that I can make sure users see it.

Some of these stories are still a bit vague. For example, the first story doesn't explain exactly how a user changes the colors. But that's okay for now. These stories are doing important foundational work: they're starting the discussion. They also demonstrate how stories provide a succinct description of business requirements. Product managers work with the development team to identify any ambiguity in the requirement. By clarifying it, the developers will be able to provide more accurate estimates.

JTBD and As a statements​

You might have noticed that the four stories in the example above have two different formats, and both use numerous "I" statements. What's this all about?

As you and your team make decisions about a product, you will have a guiding light: the intended user of your product. The user should be reflected and represented in your team's stories. So when you write a story, you should write it from the perspective of the user or person who's affected. Similarly, you want to focus the story on the problem that gets solved, not on a specific solution.

Product managers have two main templates to help them write stories: the "As a" story template and the "Jobs to be done" (JTBD) story template. The As a format is as follows:

As a [persona], I want to [take action] so that I [expected outcome].

This story format is intended to keep product managers focused on who is affected by the product and the type of feature that helps them achieve a goal. Some PMs like the straightforwardness of this format. However, others think that it's too prescriptive because it identifies exactly what action is needed, leaving less room for creative solutions.

The JTBD format is a little different:

When [situation], I want to [motivation] so that [expected outcome].

A JTBD story provides more context than an As a story, and you may discover that your teammates find that additional context valuable. It is for this reason that many teams have switched from the As a format to the JTBD format for their stories.

But writing an effective story is harder than it seems. One way to assess whether or not a story is well-written is to look at how it's framed. A good story provides ample opportunities for an innovative solution. For example, imagine it's the late 19th century, and you sell horses. You've heard some complaints from your users—the horse riders. So you write a couple of stories to determine what your users (buyers) need:

  • As a horse rider, I want to make my horse go faster so that I get to my destination quickly.
  • As a horse rider, I want to go faster so that I get to my destination quickly.

While these two stories are similar, there's an important difference. Note that the first story narrows down the possible solutions to only things that make a horse go faster. The second story opens up the opportunity for new innovative forms of transportation, like cars.

This is why it's so important to frame the story in terms of problems over solutions. Stepping back to examine the need—instead of just driving towards the initial solution idea—is where product management gets really exciting and innovation happens.

INVEST​

How do you know that you've written a good story? The INVEST mnemonic below can be used as both a guideline and a checklist to examine stories against.

Each story should encompass the following characteristics:

  • Independent: The story can be developed and delivered on its own.
  • Negotiable: The story is open to discussion, and the team can talk about different approaches and implementations (such as switching out "faster horse" for "faster").
  • Valuable: Completing the story would result in added value for the user.
  • Estimable: The story is clear enough that team members can estimate the time it'll take to complete the necessary tasks.
  • Small: The story reflects a reasonable scope of work, usually between 20 and 40 hours.
  • Testable: The story includes an acceptance criterion to help the team determine whether or not the feature met user needs.

If you've thought through the INVEST criteria, you'll be off to a good start when you discuss the story with your dev team. It is also helpful to approach the initial versions of your stories as a draft. Time and effort should be invested, but you do not need—nor should you—polish and perfect stories before sharing them with your development team. Stories will be made better by your developers' questions, clarifications, and input.




Writing great stories​

The ability to write effective user stories is a core product management skill. Now that you know a bit about writing a story, consider the elements that might be included in one.

Story points​

Like the INVEST mnemonic says, stories should be small and represent estimable chunks of work. To achieve this, you should sit with your dev team and discuss the stories. Then, the team estimates how much work each story will take. In user stories, that amount of work gets translated to story points—an abstract measure of the effort required to complete the story. The more points a story has, the harder or more complex the task is to complete. Teams use a variety of measures to calculate story points:

  • T-shirt sizing: Stories are measured into small, medium, large, or extra-large sizes. Teams often map each size to 1, 2, 3, or "more than 3" days of effort, respectively.
  • One, two, three, four: Similar to T-shirt sizes, teams use the numbers 1-4 to size a story, where 1 is about a day (or less) of work.
  • Fibonacci sequence: Teams use the numbers 1, 2, 3, 5, 8, 13, and 21 to size stories (each number in the sequence is the sum of the previous two). When using this method, 1 typically represents either a day or half-day of work. This lets teams incorporate bigger stories into their sprints.

When you sit down with your dev team, they'll discuss and then estimate how many points a story should have, perhaps using one of the scales above. Based on their estimates, you might decide to modify your story. For example, if you have an extra-large story, you should try to break it down into smaller stories. That will help your team provide a more accurate estimate.

Story points are a valuable metric, but it may take a few sprints for your team to estimate these points accurately. Over time, the repetition of Scrum sprints and the retrospective meetings will help your team improve their communication and story point estimates.

KPIs or outcomes​

Each user story should have specific KPIs or goals that indicate what success means for it. The outcomes you decide on become the testing criteria or metrics that you and your team can use to confirm that the feature works as expected.

Some stories have specific goals. For example, if you're adding a complex new feature to your home page, you could create an outcome, like "This home page should load in less than two seconds." Then you can set up tracking to ensure that the home page is loading within the desired time. Other outcomes may just be detailed explanations for the expected results, such as "After a new logo is uploaded, it's immediately updated for all clients on their next page view."

UI mockups​

Depending on the nature of the user story, new features might refer to relevant functionality (like "in the user profile") and may require a mockup. Different teams handle mockups in stories in different ways. Some dev teams like to include the mockups in the epic; others require all mockups to be completed before they will even consider estimating a story. And some teams only require wireframes to make an estimate. It's critical that you speak with your development team about how and when to include mockups in the stories you create.

Error states or data checks​

Imagine you have a form in your product where people are creating usernames, and these usernames can only include letters and numbers—no symbols. What would happen if a user tries to use a symbol when creating a username?

Take time to think about how you want your product to respond to errors. Some organizations have a standard or centralized approach to the messages that will appear in these error states (such as using a very official tone or a casual, humorous tone). In other organizations, the product manager may need to define these during feature implementation.

In either case, likely user errors and the system response should be captured; the story should be clear about exactly what should happen in an error state. Data checks attempting to automatically prevent users from submitting erroneous information may also be implemented (such as a form that doesn't accept an invalid email address).

Acceptance criteria or test script​

Acceptance criteria or test scripts define the specific steps and checks that you will use to determine when a feature can be considered complete. These should reflect the objective stated in the user story—not specific details on how the feature may have been implemented. They should be clear and simple; everyone who views them should understand exactly what the correct version of the user story looks like when it is completed.

Test scripts focus on whether or not the story performs the function correctly. For example, if your story is to implement a quick-view button in your e-commerce product catalog, the test script may look something like this: "After pressing the quick-view button, a window with the product information appears." The test script should include the exact steps to ensure that the feature works like it should. If your feature should trigger error messages in specific conditions, that kind of information will usually be found in test scripts.

Acceptance criteria is a broader term; these can include performance and nonfunctional evaluations, often focused around user expectations. For example, "The quick-view window opens and fully loads within 0.5 seconds 99% of the time" is a performance acceptance criteria. It ensures that people have a good experience using the feature. Nonfunctional criteria can include things like security or usability elements, for instance: "The window appears correctly on both mobile and desktop browsers." You'll learn about testing in more detail in a future checkpoint.

Adding and completing user stories​

When should you create a new user story or epic? Anyone—from a technical team member to business stakeholders and even clients—can contribute ideas for user stories. These ideas can come in many forms. In many organizations, a feature wishlist enables teammates to make such requests. Or maybe you want to add a story based on an intriguing comment you heard a user make during testing. As a product manager, you will capture each problem and idea in the form of a new story or epic. Once you have a story written and in your backlog, you can estimate it, start planning work on it, and—if you decide to prioritize it—track it to completion.

When are you done with a story? Typically, a user story is considered complete when the product fulfills the objective of the story. Most teams believe a story is complete when the developer and product manager agree that the story is done. Other teams don't complete a story until the feature is deployed into the hands of users. No matter which definition you use, you should make sure you and your team agree and are consistent in deciding when a story or epic is done.

Breaking epics into stories​

Product managers work with the development team to determine how a feature will be implemented by breaking apart an epic into stories. Imagine you're running an e-commerce product, and your users have been complaining about the limited payment options. You jot down the epic "Add a new payment option" in your backlog and wait to discuss it with your developers.

When other more pressing priorities are met, this item finally moves toward the top of your backlog. You discuss it with your developers, who want it to be more specific. They immediately want to know more, asking, "Which new payment option should we add?" and "Where in the product should it be added?" and so on. You mention that the customers you interviewed were especially interested in using PayPal for making payments and that it would be great if they didn't have to sign in to PayPal every time they are paying.

As a result of this discussion, you rewrite the epic to be more specific:"Add a new PayPal payment option to the checkout flow." Then, you write a few stories that fit into the epic:

  • As a buyer, I should be able to select PayPal as a payment option so that I can use my preferred method of online payments.
  • As a buyer, I can log in to PayPal to confirm my account so that I can pay with it.
  • As a buyer, I can make PayPal my default payment method so that it will get used automatically on my next payment.

Do you see what happened? The initial epic "Add a new payment option to your product" was too vague. Discussing the epic and reflecting on user needs resulted in a more accurate epic about PayPal payments.

But even if you settle on the right epic, you might find that it's still too large. This is totally normal, and you should keep working with your team to settle on the right set of epics and stories. For example, your dev team tells you that they need at least one sprint to build the backend integration with PayPal payments before working on the frontend. That backend work should become a new epic and include stories separate from the frontend epics and stories.

That iteration of stories and epics is exactly what agile development is all about—working collaboratively to take large projects and turn them into small, actionable tasks.

The process of making sure stories and epics are the right size and include the right details is known as backlog refining (previously backlog grooming). You will learn more about this core product activity in an upcoming checkpoint. For now, the important thing to remember is that stories need to have enough detail to be estimated for sizing. It is perfectly acceptable for a PM to need the help of the development team to break stories into their right sizes. You don't need to fret about getting stories just right yourself; instead, focus on clearly communicating the work to be done and clarify expectations for what successful outcomes will look like.

Other requirement documentation​

Although most companies have adopted some form of agile practices for product development, there are many other methods for translating business requirements into actionable work. Sometimes, organizations use documents that complement epics and stories; sometimes, these documents completely replace epics and stories. Some product documents may be used to update a specific stakeholder group, and others may be added to a company's workflow in response to an issue encountered in the past. There are many varieties to requirement documentation, and you'll explore some of them below.

Product Requirements Document (PRD)​

Twenty years ago, every product had a Product Requirements Document, or PRD. PRDs outlined all the requirements for a product and could be more than a hundred pages long. Needless to say, PRDs were overwhelming to produce and required constant updating. And because PRDs were long and difficult to navigate, developers would rely on conversations with product managers instead of the PRD. These conversations were often left undocumented, leading to problems and confusion down the road. PRDs were central to the issues of the waterfall development process.

Although agile methodologies helped address many of these issues, versions of PRDs still exist today. Many companies use a wiki (a website that allows collaborative editing) as a centralized location to keep user stories, testing scripts, mockups, technical specifications, and other documents. This allows various implementation teams to stay in sync. Comprehensive documents like a PRD can also help large teams coordinate in ways that other management methods can't handle. For an example of a modern, lean version of a PRD, check out this Product Hunt PRD.

UML and use case diagrams​

Many organizations use standardized flowcharts and diagrams to capture product requirements. The Unified Modeling Language, or UML, provides one approach. UML is a series of diagrams that capture the way data, people, and computers interact with one another in a software system. UML is typically used by large, older companies, like banks or tech consultancies. A use case diagram is one variety of UML diagrams; it shows how different actors interact with different systems in a product.




Fake press releases​

Writing a fake press release long before the product has been developed can help stakeholders conceptualize the objectives of a project. Large tech companies—Amazon, for example—are famous for using this "working backward" approach in pitching new product ideas. When a product manager writes a fake press release announcing new features, it forces them to communicate about the project succinctly and emphasize the benefits to customers. For instance, the PM might invent quotes from clients to include in the press release, which will make them think about what they want people to say about the features. Painting this detailed picture of the end result can help the team consider project objectives and priorities from a different perspective. And a fake press release may even become the foundation for the real press release your marketing team puts together once you're ready to announce the new features—after all, you know the product best!

Product briefs​

Product briefs—also known as creative briefs—are often used by tech agencies and consultants to ensure that both the consultant and the client agree on the scope of work to be done. These briefs usually include the goals of the project, the target audience, key objectives or outcomes, specific deliverables, and the timelines. They are often considered living documents, which means that they will be updated as new information emerges and decisions are made.

Activity 🎯​

Imagine you are a product manager at Gmail. Following user testing and interviews, you want to add to your backlog a feature that would autocomplete sentences when users are composing emails (this is a feature Google actually added in 2018).

Do all of the following:

  • Write the epic(s) for this requirement. Make sure to focus on the user problem to be solved, not the specific technical solution.
  • Break down the epic(s) into stories. Consider both the backend and frontend.
  • Write each user story in both As a and JTBD form. Which approach do you prefer? Why?

Make sure you are confident working with epics and user stories—it will likely be a big part of your work life as a product manager.