User Stories are one of the most important parts of agile development.
Yes, user stories replace those traditional requirements and specifications docs. But they do it in such a different manner that casual observers wouldn’t even recognize the relationship.
One of the best user story definitions I’ve found comes from Wikipedia:
“In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded on index cards, on Post-it notes, or in project management software. Depending on the project, user stories may be written by various stakeholders including clients, users, managers or development team members.”
In this article, I’m going to put that definition into even plainer language. I’ll explain how user stories differ from traditional “old school” specifications documents, I’ll provide templates showing how they’re created, and then I’ll discuss the role user stories play in agile development.
How User Stories Differ from Traditional Tech Requirements
Those of you who’ve been in this business a while will recall how “complete” a project’s technical requirements documentation had to be. Everything was planned out up front. Every feature was mapped out and explained in painstaking detail. Every technology was specified and practically configured right there in the documentation.
You might also remember how loooooong it took to put one of those doozies together. All the discussion, planning, and negotiating. And the meetings… oh, the meetings.
Obviously, that approach didn’t fit anything with the name “agile” attached. So agile developers adopted an entirely new approach to writing their requirements: user stories.
There are 4 main differences between user stories and those old school requirements docs:
- User stories are written to describe individual features, not entire projects
- User stories are not broken down into more detail until they’re near the top of the priority list
- User stories provide guidelines, not instructions, on how to accomplish the task
- User stories are meant to create discussion, not end it
To understand this, we need to look at the structure of user stories and how they’re created.
The User Story Template
The basic template of a user story is:
As a < type of user >, I want < action or goal > so < reason or outcome >
From this template, you can see how user stories focus on both the end-user and the desired result when explaining the action to be performed.
In the beginning, you might start with a bigger, more general user story called an epic:
I want to delete emails from my inbox so I won’t see them anymore
As this epic user story climbs higher on the priority list, it will eventually be broken down into much smaller chunks, each of which could fit inside a two to four week production sprint.
An example of breaking down our deleting emails epic into smaller user stories could include:
As a mobile app user, I want to select multiple emails from my inbox so I can delete them all at once
As a mobile app user, I want to swipe to delete an email so I can delete it quickly
As a mobile app user, I want an option to archive instead of permanently delete emails so they’re not gone forever
And so on.
Who Creates the User Stories?
User stories can come from a variety of sources.
The Product Owner can write them. Other Scrum team members can write them. Business stakeholders outside the project team can write them, too.
But only the Product Owner can add them to the product backlog – the development team’s prioritized to-do list that consists of all their user stories.
And only the Product Owner can assign the priorities that determine when each particular user story will be developed.
As the manager and gatekeeper of the product backlog, it’s also the Product Owner’s responsibility to make sure that all user stories are properly written before they’re added – whether the Product Owner is the one writing them or not.
The Parts of a User Story
At some point, a user story must contain enough detail that it can be completed during a sprint.
A completed user story consists of two parts:
- The user story statement
- The user story details
The user story statement is the simple, one-line format I shared in the template above:
As a < type of user >, I want < action or goal > so < reason or outcome >
The user story details include the acceptance criteria, which I described in detail in the post, User Story Acceptance Criteria. These are the conditions that must be met for the story to be considered production-ready. These range from behaviors that must be accommodated to data formats and content validations to legal compliance and performance.
The user story details also contain any relevant notes from the Scrum development team’s discussion that will help them remember some of the finer points when it comes time to code the feature.
Some acceptance criteria will come from stakeholders outside the team. Others will be added during the Scrum team discussion. That discussion – the key points of which are captured in the user story notes – plus the detailed planning at the start of a sprint is when the team decides howto accomplish their task.
The important thing to note is that user stories can reside in a high-level, general form indefinitely but are never brought into a sprint until the Scrum team discussion takes place and the team understands the story.
How User Stories Guide Your Development
User stories do much more than offer guidance for your developers. They also guide your project’s direction in two major ways:
- They only get broken down and thought about in detail once they’ve been identified as a top priority
- They spark the discussion where the “how should we do this” decisions are made
In the first instance, user stories help keep your Scrum development team focused on what’s most important. Because user stories aren’t fully detailed until they’re queued up for inclusion in an upcoming sprint, your team won’t get sidetracked by distant challenges. And since many user stories might never end up near the top of the list at all, that’s a lot of time saved over the course of your project.
In the second instance, the user story is what the Scrum team’s discussion revolves around when they decide how to build a feature. Traditional requirements docs handed developers their instructions, effectively ending further discussion. User stories start the discussion, and the development team is responsible for making those decisions.
And here’s another tip I’ll share about user stories… the better your development team’s user story discussions are, the better their solutions – and the resulting product – are likely to be.
