What’s a User Story?

A user story is a description of a change in system behavior from the perspective of a user. Each story should add an increment of value, but you will likely have to accumulate a handful of stories before you have enough value to be worth shipping (hence the MMF). Nonetheless, because user stories are complete slices of new behavior, they give a better indicator of progress toward the MMF and a better increment for seeking feedback from stakeholders.

Stories often follow the format: “As a <role> I want <action/feature> so that <value/goal>.” Or, sometimes, stories will use an alternative format: “In order to <value/goal>, as a…” The format isn’t the important thing, though. What’s important is answering the questions raised by the template: Who wants this? What do they want? Why?

To that end, teams who use stories fluently rarely write a story in one of those formats. Instead, they’ll answer the three questions in different places. If a story is for the main role, which is described in a product vision, they’ll omit the role for that story. They’ll use a short, two- to four-word title at the top of the story card or in the story title field in a digital tool. And they’ll just write the “why” on the card or in the story description field. It looks something like that shown in Figure 1-3.

So how do you get good user stories from an MMF? Just as you did with feature mining to slice a big idea into MMFs, you can ask the four questions about value, size, risk, and uncertainty. At the MMF level, though, you’ll often have enough of an understanding of value, risk, and uncertainty from doing feature mining that you won’t need to formally answer those questions. The interesting question here is, “What makes this particular MMF big?”

Patterns for Splitting Features and Big Stories

There are some common patterns for what makes features big and corresponding ways to split through that complexity to get good user stories. Let’s look at a few.⁴

Sometimes an MMF is big because it describes a workflow with multiple steps. If you can describe the user experience of your feature with at least three boxes and with arrows between them, as shown in Figure 1-4, you probably have one of these workflow features.

In this case, look for a story that takes a thin slice through the whole workflow. For example, if you had a feature about finding and borrowing a book, you might split it so that the first story only offers the opportunity to borrow one hard-coded book, or you might allow patrons to find and borrow a book but not to accumulate multiple books in a cart and borrow them all at once. Then, write additional stories to account for the missing pieces to flesh out that workflow.

Sometimes an MMF is big because it includes multiple operations, where you’re allowing the user to manage some entity in the system. In this case, you could split the feature into a story for each of these operations. For example, “Manage my library account” easily splits into

• Create my account

• View my account details

• Change my password

• Change my account details

• Cancel my account

• Etc.

Other times the MMF is big because it includes many business rule variations, which we could split across multiple stories. In Chapter 6, “Making Scenarios More Expressive,” we look at an example of the library team working on the logic around fines for returning books late. There are many different business rules for fines based on whether you’ve borrowed a book or a DVD, for example, or whether you’re a child or an adult. These rules can be sliced into separate stories.

Sometimes, it’s not the variety of rules that makes a feature big but the variety of data that needs to be tested through those rules. For example, maybe the library catalog needs to support multiple languages. The rules are the same for each language, but working with the different languages may reveal edge cases and bugs, so each significant variation needs to be tested. You might choose to start with just one or two representative languages rather than supporting all of them from the beginning.

Occasionally, a complex user interface makes a feature big. In that case, we can often slice the feature to use a simple interface first and enhance it with the full-featured interface later. This is particularly useful when the value or learning is mostly associated with the behavior rather than the interface, and the interface just adds incremental value.

Often a feature has a simple core, a “happy path,” with many variations and enhancements. That simple core can be its own story, and then the variations can be grouped into several more stories. This approach helps you focus on what really matters in a feature. You might not even end up building some of the variations.

Choosing a Story to Start With

So, you’ve split your MMF into a handful of user stories; which one do you start with? Does it even matter? An MMF, by definition, will be released as a single unit. We’ve defined anything less than the MMF as less than marketable. So, we don’t worry much about prioritizing by value within an MMF. Instead, we prefer to prioritize by learning and risk mitigation. We’ll look for a story that will teach us something about the problem or solution. Often, this is the story that will get us the most feedback from a key stakeholder to confirm that we’re solving the right problem or solving it in a useful way. We can safely leave the least risky or least informative stories for last.

If you’ve used feature mining to find your MMF, you probably already listed the questions you need to answer and risks you need to mitigate. These lists can help you prioritize the stories.

Keeping It Minimal

As you split an MMF, you’ll think of new variations you weren’t aware of at the beginning. Remember the first M of MMF, minimum. Each story should earn its way into the MMF. Ask yourself questions like, “Is this story essential to this MMF or is it something we could come back to later?” You don’t want nice-to-have stories holding essential stories hostage.