User Stories are not always User Stories

Sometimes User Stories are not User Stories but something else: Epics, Tasks, Acceptance Criteria, or Definition of Done. By giving examples of these cases, I hope to help product owners, business analysts, requirements engineers, scrum masters, and developers improve their agile requirements engineering process.

Christian Hujer, Software Crafter and CEO / CTO of Nelkinda Software Craft Private Limited
First Published:
by NNelkinda Software Craft Private Limited
Last Modified:
by Christian Hujer
Approximate reading time:

1 Introduction

These days, User Stories are the key element of agile requirements engineering. Together with other things like Epics and Tasks they are PBIs aggregated in the Product Backlog. Typically User Stories start with a headline in the form of a sentence filling a template like the following:

As a Role, I want to action in order to purpose.
User Story Template

I think that this is a good template for the headline of User Stories. But it doesn't mean that just pressing the headline of your requirement into that template automatically makes it a User Story.

Your requirement could actually be something else. Not every requirement is a User Story. We can categorize requirements which sound like User Stories into the following groups:

Besides, there are other criteria that good user stories should follow. I recommend INVeST.

As a
I want to
save a file
in order to
persist my work.
Figure 1-1: User Story Card Example

Please note that the examples given here are just rough guidelines. In an ideal world, a User Story would always reflect work at a granularity that delivers true business value. True business value is value in the eyes of customers and users.

Experience, environment, tools, libraries and existing code are just some of the many factors which influence the speed at which a team adds value. Each team faces their own situation influenced by these factors. Therefore, the examples given below should be seen as guidelines, not as hard rules. The breakdown of a vision into a tree of epics, user stories and tasks will happen according to a scale. That scale might have to shift to the bigger or smaller depending on the speed of the team. At the same time, I would invite teams that move so slow that they cannot apply the scale used in the examples to think: There are impediments which slow us down, like viscosity.


INVeST is a mnemonic acronym that describes some important criteria for User Stories. Ideally, we should also try to apply this acronym to other PBIs in general. The following short description of INVeST is paraphrased from [INVeST].

User Stories should be independent of each other so that those with higher Business Value could be implemented first.
User Stories should be negotiable to strike the optimum balance between what is technically possible and what business needs.
User Stories should have real measurable value for the business and its customers so that they can be prioritized.
Estimation is needed for business in order to come up with a plan.
Smaller User Stories can deliver business value more timely with less risk.
Without testing, there would be no way to tell whether a User Story is complete.
Definition 2-1: INVeST paraphrased from [INVeST]

I like to add another element to this list:

Demoable (aka Demonstrable)
The User Story describes a business value that, once implemented, can be demonstrated to the stakeholders.

3 Epics

As a User, I want to edit Markdown files in order to work with a convenient format capturing 80% of day-to-day formatting requirements.
A requirement that sounds like a User Story but in fact is an Epic

This sounds like a User Story. But it's actually very big and can be broken down into various separate User Stories. Examples include loading, saving, syntax highlighting and WYSIWYG editing of Markdown files. Those broken down User Stories are smaller and still have a business value of their own. Each of them would individually already help a subset of users interested in the Markdown feature.

4 (Proper) User Stories

As a User, I want to save a file in order to persist my work.
Proper User Story

This is a clear user story. It is end-to-end, and it can be easily implemented. Of course, there are a few details to clarify to get the story ready and done, like:

5 Acceptance Criteria (of other User Stories)

As a User, I want to trigger save with Ctrl+S in order to work more efficiently.
A requirement that sounds like a User Story but is Acceptance Criteria

This is usually too small for a user story. It should rather be an acceptance criterion of the bigger User Story which talks about saving a file:

  Scenario: Saving a document with Ctrl+S when it has a filename
    Given I have a document with file name
    When I press "ctrl pressed S"
    Then the "save" action must have been triggered

  Scenario: Saving a document with Ctrl+S when it has no filename
    Given I have a document without file name
    When I press "ctrl pressed S"
    Then the "saveAs" action must have been triggered
Listing 5-1: A requirement rewritten as Acceptance Criteria in Gherkin

6 Definition of Done

As a User, I want to trigger actions via keystrokes in order to work more efficiently.
A requirement that sounds like a User Story but is Definition of Done

While it sounds like a User Story, it actually isn't. It is orthogonal to stories and part of the Acceptance. It isn't applicable to a single User Story or a very particular small subset of User Stories. It is applicable to an entire category of User Stories. In a GUI application, it is probably even the majority of User Stories. Therefore, this requirement is best captured as part of the Definition of Done.

Also, this element of the Definition of Done feeds back to the Definition of Ready:

The User Story specifies the keystrokes for its actions.
An element in the DoR that relates to the discussed DoD element

7 Technical Task

As a Developer, I want to run DynamoDB on my machine in order to debug efficiently.
A requirement that sounds like a User Story but could be a Technical Task

This could be a User Story if the demand for running DynamoDB for debugging locally is coming from the business. And this demand could come from business in case running DynamoDB remotely involves extra cost.

But for now, let's assume that the remote DynamoDB comes free of cost (it doesn't). In that case, there is no direct business need for having DynamoDB locally on developer machines.

Let's look at another one.

As a Developer, I want to deploy the application on AWS in order to put it into production.
Requirement that sounds like a User Story but is a Technical Task

You might already recognize a pattern here. There are things which development teams need to do for themselves in order to do their job. Tasks which are important to be done but have no direct visibility to the business. Ideally, those tasks should be associated with a corresponding story or epic. But that's not always possible.

The common pattern of these requirements is that, if formulated as a User Story, the role will usually be related to the development team.

Such requirements are useful for the development team. But they are not valuable for the user or consumer. Thus, they should be technical tasks, not user stories.

8 Conclusion

Not everything which sounds like a User Story actually is a User Story. Instead, what sounds like a User Story sometimes is something else. Candidates are at least Epics, Acceptance Criteria and Definition of Done.