Creating Epics and User Stories

Epics and User Stories put the stakeholder in the centre and help you to communicate business value

A simple example of a User Story. The Acceptance Criteria would be at the back.

The story of Rappi, a Colombian on-demand delivery app, is a great example for the benefits of a stakeholder-centric approach to designing applications. Rappi is a mobile app that was initially focused on allowing customers to easily order food staples and meals and have them delivered to their home.

Luckily, the app featured a blank box from the beginning, in which customers could freely specify what they wanted to have delivered. It turned out that many users wanted far different things then just ordering groceries from the local supermarket. Rather, they wanted to have their dog walked by the Rappi delivery driver or even asked for cash to be delivered to them from an ATM machine.

Rappi is just one of many examples for software applications that have been built with a strong stakeholder focus and had their user experience adapted on the go based on user feedback. The key is to the try to first anticipate your stakeholder's needs as good as possible, but to eventually let stakeholders feedback decide into which direction to go.

What Are Epics and User Stories?

Both Epics and User Stories are Product Backlog Items that articulate the needs of stakeholders in succinct natural language. Their aim is to describe the benefit of using the application from a stakeholder's perspective, instead of taking a system-centric view. Remember that each Product Backlog Item that is later implemented needs to be first ranked by its business value. It is exactly this value that the Epic or User Story tries to emphasise.

Naturally, this implies that prior to writing an Epic or a User Story, the stakeholder's needs should have been recorded and understood, e.g. through performing a Contextual Inquiry. This need is then distilled into a single sentence in a potential standard form which we will outline below.

It is important to note that the Epic or User Story as such do not provide a detailed specification of what needs to be implemented. Their goal is rather to incite discussion between the stakeholders and your team on what needs to be done. A more detailed specification is provided in the Acceptance Criteria that are attached to the Epic or User Story.

What Distinguishes an Epic From a User Story?

There are several (equivally well motivated) views on how to distinguish the two. Mine is as follows: An Epic is a Product Backlog Item that, in contrast to a User Story, takes more than one iteration to implement. Additionally, its "epic" characteristic implies that it may impact not only one, but several stakeholder groups.

Although the latter characteristic is not commonly used, it makes sense given that a "large" User Story will very often implement features that realise several stakeholder's needs at the same time. Take, for instance, an application which allows field workers to record and view data related to their assignment. The same view could be also used for office clerks who need to ensuingly process the assignment, rendering this need a common need for two different stakeholders.

Creating an Epic or a User Story

Now, imagine that you have a concrete need that has been voiced by one or several stakeholders. You know that implementing that need in your application will take at least two 2-week iterations, potentially more. Then you can create an Epic in your Product Backlog.

An Epic consists of a natural language description that can be phrased using the following template:

As a <stakeholder 1>, <stakeholder 2>, ..., and <stakeholder n>,

I want <stakeholder need>

so that <business value>.

Insert the types of your stakeholders, like "field worker" and "office clerk" into the <stakeholder> placeholders. The <stakeholder need> placeholder should contain a succint description of the stakeholder need, e.g. "to record and view assignment data". Finally, the <business value> placeholder should be replaced with a very brief description of the business value, like, for instance, "I can quickly handle and process assignments."

The final Epic then looks as follows:

As a field worker and office clerk,

I want to record and view assignment data

so that I can quickly handle and process assignments.

Often, User Stories can be derived from Epics, i.e. one Epic can be broken down into several User Stories. This approach can help your team translate multi-iteration Epics into Product Backlog Items that can assigned to different iterations.

You can create a User Story using the same template as above, but make sure to only include a single stakeholder. The above Epic can, for instance, be broken down into two User Stories, with one describing the need from a field worker's and the other one from an office clerk's perspective. Although both have the same originating need, their User Stories can express slight variations in their stakeholder need (e.g. the office clerk might only want to view and, if needed, change assignment data) or business value.

Adding Acceptance Criteria

Acceptance Criteria play a very important role, since they define and constrain the solution space. Let me explain that: Epics as well as User Stories should only state the need voiced by the stakeholder, not define the solution. So how do we ensure that nevertheless certain preconditions, boundary conditions or aspects of the need are still being met? Attaching Acceptance Criteria to your team's Epics and User Stories is a good way of doing that.

Acceptance Criteria are natural language statements that describe the above points in the form of an unordered list. They thereby reduce the variety of different solutions that can be chosen for implementing an Epic or a User Story, i.e. they constrain their solution space. In an Epic, they mainly fulfill the important role of scoping, while in a User Story, they often concretise the stated need.

For the above example Epic, possible Acceptance Criteria could be as follows:

1. Each assignment is allocated to exactly one field worker and office clerk

2. The view needs to be able to displayed on mobile devices, tablets and desktop

3. The assignment number can be entered and changed in the data

How Do You Become Entangled?

By creating Epics and User Stories, your team has already tried to answer the following important questions:

1. Which stakeholders am I building my product for?

2. Which needs do my stakeholders have?

3. How much business value can be attributed to each need?

The key is to ask yourself those questions over and over again and to never shy away from considering a new or different answer. If your team manages to always be ahead of the game, then you can consider yourself and your product to be truly entangled to your stakeholders' needs.

Care to Know More?

Just a few words about how you can make your Epics and User Stories available to your team: The easiest way, which I would recommend to teams that just started working agile, is to use a physical board with physical cards, as pictured above. There is of course also a plethora of software applications available in which you can create Product Backlogs and let your team work on them. In a future post, I will compare the most well-known tools and will even give you a recommendation on which one to use.

I also did not mention agile estimations yet, which can play an important role in implementing Epics and User Stories. Please stay tuned for a future post on that topic.

Would you also like to know more about this post's topic? If so, then please post your questions in the comments below and I will be answering them. If the subject of your question is a hot topic, then I will dedicate a post to it in the future.