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:

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:

• Epics
• (Proper) User Stories
• Acceptance Criteria (of User Stories)
• Definition of Done
• Technical Task

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

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.

2 INVeST

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].

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

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

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:

• file format, file encoding
• menu position, mnemonic, icon, and text; toolbar position and icon; tooltip text; keystroke

5 Acceptance Criteria (of other User Stories)

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

6 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:

7 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.

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.