A user story is a short description of functionality, sometimes written by an actual user but more often written by a proxy for the user, either a product manager or digital business analyst. They are generally small, and strive to outline a single piece of functionality, the general structure for a user story is as follows:
As a <role>, I want <goal> so that <benefit>
User stories aren’t expected to include every requirement for the functionality, they serve to initiate a conversation between the user (either directly or by proxy) and the developer, so don’t be surprised if the development team have a bunch of questions, that means things are going well!
Acceptance Criteria
User stories also include anacceptance criteria, which become the basis for the functional tests and are incredibly useful for QA team members to use to identify when the functionality is complete.
Tip: I often use the Acceptance Criteria during the development process to create automated tests, which save time when the work makes its way to a test environment.
Examples of User Stories
As a user, I want to search for eggs by size.
Notice in the above example that we are missing the ‘so that <benefit>’ part? This bit is optional and shouldn’t be included just for the sake of it.
The role isn’t always the user, in some cases a development team may have tech housekeeping or technical debt to clean up, so will become the role:
As a developer, I want to seed data for the mortgage calculator tool, so that I don’t need to enter it manually.
I’ve included a benefit in the above story, this can be handy when communicating with the business the value of the internal tech debt work, in this example the developer is required to enter something manually at the code level.
Now lets see an example where we are defining a role ANDa function:
As a user (role) exiting the game (function), I want to be reminded that exiting without saving is a bad idea (desired functionality), so that I can preserve my progress without starting again (benefit).
Epic User Stories
Really long user stories (several sentences, paragraphs or even pages) are referred to as ‘Epics’ and the challenge with epics is to deconstruct them into smaller, more actionable user stories. The goal of the stories is to give the developers actionable chunks of work, giving them 6 pages of requirements won’t make you any friends.