Epics and Stories

Over the course of the last several chapters we've detailed parts of the agile planning process designed to take a software application from initial conception through detailed user interface wireframes. This chapter marks a turning point in the agile planning process, where we really get specific about what we are going to build by methodically breaking down our scenarios, storyboards, and wireframes (our artifacts) into smaller and more well defined chunks in order to achieve some key goals:

• Smaller chunks of functionality are easier to estimate in terms of complexity, thus providing a facility to plan for development capacity and timing.
• The process of breaking down large features squashes out ambiguity and flushes out assumptions about how something will work.
• Small chunks of functionality are more likely to be completed during the course of a typical development iteration (sprint) and allow the team to continuously deliver working software.

The Gravel Factory

Before we dive into the nitty-gritty process, we will begin with a metaphor for how we should think about breaking down our artifacts into the smaller chunks of functionality (known as "Epics") and the still further smaller chunks (known as "User Stories" or just plain "Stories").

Imagine your goal is to continuously deliver a fine grade of gravel to your customers, who happen to need it to build roads, foundations and so forth. You start with huge boulders delivered from the quarry, the size of cars. None of these are even remotely usable by your customers, they know that ultimately the boulders will turn into the gravel, but need them to be crushed first. Your factory starts by exploding a boulder into much smaller rocks. And then takes several of the rocks and crushes them into stones. And finally a portion of these stones and grinds them into the final gravel your customers need.

This is how we should think about breaking down an application into Epics and Stories. This story is designed to illustrate two lessons:

1. This breakdown process is just-in-time. Note that we specifically did not explode all of the boulders to rocks at once, nor grind all the stones to gravel. Why? Well that would take a lot of time, and our customers need the gravel now! Also what if one customer wanted a finer or coarser grade of gravel? If we did all the processing at once we could only provide one type. Similarly while breaking down our artifacts, we try to do so such that we can deliver Stories to the development team just-in-time for them to work on them.
2. This breakdown process is continuous. When we talk about the breakdown process, we are talking about a continuous process, but one that does indeed begin when a project kicks off. Just as new boulders will arrive at the gravel factory, so too will new user scenarios, wireframes, and storyboards be generated as the product or application grows. Each will need to be continuously broken down into smaller and smaller parts before the development team can start working on those parts.

You'll notice that this breakdown process is very similar to the process overview we discussed earlier. A large idea is broken into several smaller ones, then one of those is further divided and so forth. In order for the software developers to continuously deliver working, valuable software, we must first continuously deliver detailed specifications.

What is a User Story?

In the context of Agile software development, a user story (or epic) is a very specific thing. It is a way to describe application functionality in a way that focuses on the end user and the benefits they derive from the feature. (Source: https://www.scrumalliance.org/community/articles/2013/september/agile-user-stories.aspx)

There is a specific format used to write user stories, they don't need to be long and involved, they only need three parts:

In order to _achieve some value_
As a _user type_
I want to _perform an action_

This can be just as correctly written user first:

As a _user type_
I want to _perform an action_
In order to _achieve some value_

Some organizations prefer to focus first on the user involved, some prefer to focus on the value derived. You should decide early on in a project what your format is and stick to it. Each of the lines is necessary to form a good user story or epic:

User Type: The Who

The user type should describe a class of the application user, these should typically map back to the either the personas we created or specific application roles. Defining the user helps the whole development team understand who will be using the feature, and what their motivations and needs are. For example:

As a soccer mom user...

Would set a different context than:

As a corporate executive user...

Perform an Action: The What

The action is the actual functionality that the story describes, this is ultimately what will be expanded into either more detailed stories (in the case of epics) or detailed acceptance criteria. The scope of this action helps to classify the size of the story. Here is an example of a small action statement:

I want to save a single todo item...

And one which is more involved:

I want to organize my todos into categories...

Determining how "big" a story or epic is can become more art than science and is something that will come with experience. We discuss a little later about ways to think about the size of a story.

Achieve Some Value: The Why

The final part of a user story is describing the value that is achieved for the user by implementing the desired functionality. This sentence describes why we are even bothering to build the functionality and sets context for everyone involved in the planning process. When developers know the reason behind the need to build a certain feature, they are better positioned to use their creativity to deliver a quality solution. For example, in the story:

As a soccer mom user
I want to organize my todos into categories
In order to focus on a specific set of items while working

The last line let's us know why the user wants to do this organization.

It's important to remember that the value described in the user story should be aligned to the user in the story. It is value they are trying to achieve which will in turn create value for the total product and business. You should avoid the "because I said so" type of user stories, for example:

As soccer mom user
I want to link my social media profiles to my account
In order that the marketing team can track social engagement

Clearly if you asked any of our example users, they almost certainly would not have the interests of the marketing team motivating their desire for features. By writing stories this way or, worse, not providing the "why" at all, allows lots of assumptions to creep into the feature specification process. If the why is not provided, a sinister "implied why" might be inferred: "because story writer knows best," which stifles the necessary negotiation over the priority of a feature, how it's implemented, and if it is even needed. Furthermore, having user stories motivated by non-user needs is a sure-fire way to lead to feature bloat, delivering an overly complicated application that isn't geared toward solving the users' problems.

A Placeholder for a Conversation

A user story is composed of three parts: the who, the what, and the why. But remember that ultimately a user story is just a placeholder for further discussion among the team. We avoid specifying details and implementation in user stories precisely to encourage the conversation and defer specifics until the last possible moment, when we know the most.

Would you pack for a weekend camping trip 3 months in advance? You could, but you'd either have to pack all sorts of different things to account for the weather or risk packing your hot weather gear, only to have it rain the whole weekend. It would be better to pack the night before, knowing with confidence what the weather will be like.

We take this same approach in both the specification and breakdown of user stories and epics. We make a note of the feature, in the form of the story, and then when it is ready to be worked on, bring all of the most up-to-date information to bare. What does this look like for an example story? Consider the following:

As a soccer mom user
I want to share a todo category with a friend
In order that they can help me with my tasks

There are a lot of details and specifics that are required to actually implement this feature. You might be thinking of several questions as you read through it. The best place for these details to be fleshed out are conversations with the product designers. Ron Jeffries developed a concept called "The 3 Cs" to describe story creation and the necessary discussion: Card, Conversation and Confirmation:

Card

Whether you enter your user stories in a software base management tool or really write them on an index card, all user stories should be thought of as being on a card. Cards are small and can't contain a lot of information, just the simple As a..., I want to..., In order to.... It "does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement." (Source: http://xprogramming.com/articles/expcardconversationconfirmation/)

We have a general idea of what the above story might look like: the user will probably go to their todo categories page, select a category, chose the share option, select a friend, and have some facility to manage their friends. The story is sufficient to evoke an idea of what is going on in the minds of the development team.

Conversation

The conversation is critical to turning the simple story into something that can actually be built. In the discussions with product managers and designers, software developers will learn the ins and outs of the feature, what the interface should look like, what the user experience flow should be, what performance requirements are needed and so forth. Stories are planned iteratively, each time with more information known. In the discussions we might learn how the friend selection interface should look, that we have a have a set of social network integrations we need to support, that there should be a button on a todo category page that says "Share with Friend," and other things like this.

Confirmation

The confirmation step is a way to formally capture the many conversations that take place in defining a story. These can take the form of documentation, use cases or design wireframes, but the best way to confirm a story is to write acceptance tests.

The conversations that occur in preparing a story might be captured by a list of specific tests that could (and should) be automatically run to verify that what we wanted to build with the simple story sentences is built fully to everyone's satisfaction. This is where the rubber meets the road. One example of a confirmation acceptance test for our example story would be:

Given I am on the "todo categories" page
And I have a todo category called "Work"
And I have a friend called "Sue"
When I click the link "Work"
And I click the "Share with Friend" button
And I select "Sue" from the "Friends" drop down
And I press the "Confirm Share" button
Then I should see "The Work category has been shared with your friend Sue!"
And "Sue" should have access to my category "Work"

This is just one of many necessary acceptance tests that will be needed to get everyone on the exact same page with regards to what actually needs to be built.

By remembering that a story (or epic) is just a placeholder for a conversation, you will be in the right frame of mind for the actual process of breaking down our user scenarios into smaller and smaller pieces. A team can get bogged down discussing implementations and spit-balling about great features and how things work. By focusing on user needs and deferring the details until you are ready to build, you can efficiently create a large product backlog with considerable flexibility in final implementation.

Building the Backlog

Now that you have a fairly good handle on what a story is and how to write a good one, you are prepared to learn about the process of "crushing that gravel." That is, breaking down the large user scenarios into epic level stories, and then smaller stories, so that you have a bulk of work that can be planned and built.

The Story Writing Workshop

At the beginning and through the development of an Agile software product, the product development team will collaborate on filling out the backlog of user stories. Though typically composed of product managers and designers, it is important to also include test engineers and developers as their unique perspective can inform the writing process. Engineers could say that something is nearly impossible, or help decide if a story needs to be broken down further or other stories combined based on technical difficulty. "Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of Agile user stories exists, but that doesn't mean that the product owner is the one who writes them. Over the course of a good Agile project, you should expect to have user story examples written by each team member. Also, note that who writes a user story is far less important than who is involved in the discussion of it." (Source: https://www.scrumalliance.org/community/articles/2013/september/agile-user-stories.aspx)

The workshop should not be considered a one-time thing, but the first of several used to bulk up the backlog for development. A project might begin with one large writing workshop, then as the product develops, stories will be regularly added and prioritized into the backlog.

The goal of the initial story writing process is to create enough estimable stories that the development team can use to plan a release, which we will cover in the next chapter. You may start a project with several user scenarios, which each could expand out into numerous epics, and then those in turn would turn into many stories. If your team were to attempt to break down the whole of the product into every story, it would be very difficult, if not impossible for two reasons:

1. Fatigue - There is no way a product team could realistically work together for the days it would take to write out hundreds of user stories. After a few hours, people will grow tired, less concerned with the task at hand and lose the creative edge. Break the workshop into a couple of small meetings, with defined goals. Give people a chance to mentally recuperate.
2. Uncertainty - Many of the features may not be wholly known during the writing workshop, the very process of participating in the workshop may create new questions, new feature ideas, and opportunities for further user research. It might simply not be possible to define all the stories so far in the future. Furthermore, likely the needs of the user could change, the team will discover more required features along the way, and ones which initially were thought important might become irrelevant.

And so as you work through your process of breaking down scenarios, be strategic about it. You may leave some scenarios until future workshops. Break down the most important into several epics, and pick several high priority epics to break down into stories. Remember the gravel metaphor: the development team needs small, well defined stories to plan and execute, the first workshop is simply to get the project started.

Creating Epics

To illustrate some of the nuances that arise while breaking down user scenarios, let's work through an example based on two of the previously listed user scenarios. Here they are again:

Scenario 4: Organizing Todos into Lists

Janet has lots of things to keep track of at work, at home, with her kids, and some times she has missed important todo items because they have been cluttered up with less important ones. She finally has a little free time while waiting for her kids at the schools pick up area. She pulls our her iPad and launches our application. She creates a few "lists" for different areas in her life: work, kids, finances, errands, dog, and home. Then she starts moving all of her existing todos into each of the lists. When she is done her todo list is very organized and at a glance she can see what needs doing. At work she focuses on the "work" list, and when she is talking with her children she is sure to add any relevant items to the "kids" list.

Scenario 5: Sharing Todo Lists with Friends

Janet is relived that her husband is home for a few days from one of his many business trips. He has a few days off, but its a particular busy week for Janet and she is hoping she can offload some of her typical todos onto her husband. The house is out of a ton of groceries and the kids need materials to build a science project. She creates a list for "groceries" and jots down all of the items they need from the store, she also moves in the todo item "construction paper" from the "errands" list and "dog food" from the "dog" list. She then shares this list with her husband. He receives an email and is able to view and mark things completed on this todo list. He goes to the store and gets everything that they need.

Once the team has decided which high priority user scenarios it will try to fulfill, the next step will be to define several epic level user stories with the goal of capturing the critical tasks that the users complete when interacting with the software. It might be helpful to think of epics as blocks of functionality that have value to the end user in total, while the stories that they are composed of, even though they do deliver value to the user, need to be joined to other valuable stories to "actually do anything that's really valuable." For example:

As a User
I want to reset my password
In order to access the application again

This could be thought of as more of an epic when compared to the stories to which it might be further broken down:

As a User
I want to receive an email with password reset instructions
So I can finish the password reset process

Alternatively, it could also be helpful to simply describe the stories as needed to break apart the scenario, and then revisit them, classifying those that need further granularity as epics, and those that could realistically be built in a sprint as a story.

After a team has spent some time with both of the above scenarios, they might come up with several epics that define core user tasks:

As a soccer mom user
I want to organize my todos into categories
In order to focus on a specific set of items while working

As a soccer mom user
I want to manage my todo categories
So that I can keep them organized and up to date

As a soccer mom user
I want to share a category with a friend
In order that they could help me with my tasks

As a non todo app user
I want to access a category which has been shared with me
So I can help the app user with their tasks

As a soccer mom user
I want to manage which categories have been shared
So I can un-share them if I need to

These are just some of many epics (and these are reasonably sized epics) that may come about while working though the break down process. As the team discusses the user needs they'll inevitably cover things like account management, profiles, security, and so on. It's important that the team steers the discussion toward achieving specific user scenarios, and tables some of the "nice-to-haves" for future planning sessions. There can be a lot of value in just building the "minimum" required to achieve the user needs. The software is less bloated, can be delivered more quickly, and time can be devoted to validating other features before they are rolled into the product backlog. Check out the advanced material at the end of the chapter for more information on building the minimum.

Breaking Down Epics to Stories

After several high priority epics have been developed, the team may switch gears and start further breaking down some of the epics into more granular stories. Let's take a look at one of our epics and then several of the stories it might spawn:

As a soccer mom user
I want to share a category with a friend
In order that they can help me with my tasks

This epic is a little vague and one you start thinking about all the moving parts that would go in to building it, it quickly becomes apparent that it could be split into several more atomic stories:

As a soccer mom user
I want to add a friend to my account
So that I can share a todo list with the friend

As a soccer mom user
I want to remove a friend from my account
So they won't be able to access categories I had shared with them

As a soccer mom user
I want to share a category with an existing friend
In order that they could help me with my tasks

As a soccer mom user
I want to see which todo items my friend has marked completed
So I can keep track of which ones I've done versus them

There likely could be additional stories to support the epic of sharing a todo category. Notice that each of the above stories is valuable in the context of the epic, but not really valuable in and of themselves. There is some close dependencies with these stories, but they are still relatively independent and negotiable. The team could defer several of these stories if conditions warrant and still achieve the intent of the epic.

Writing good user stories is as much of an art as it is a science, a skill you will improve over time as you practice and understand your product and development team. Writing user stories collaboratively can improve the process. More questions will be asked, silly mistakes avoided, and higher quality stories will be developed. As stories are ultimately built, make a note of which ones were difficult to plan further or build, and see if there are any patterns and adjust accordingly. Just as with everything in Agile software development, use feedback loops to constantly improve.

What's Next

In this chapter we took our product design artifacts (personas, scenarios, storyboards, and wireframes) and discussed continuously defining feature requirements at a more and more granular level, so that engineers have a very clear idea of what they are to build.

You should have a good sense of:

• What a user story is, and how to write a good one.
• How we break down user scenarios into epics and then user stories.
• That these processes are continuous, often happening on a large scale at the beginning of the project, and many times throughout the project.

In the next chapter we will discuss the concept of the product backlog which is the large set of all the stories and epics you created while working through this chapter.