Most product development starts with an end goal: You want your project to accomplish a specific set of tasks for your end user. But simply hacking away at a nebulous, massive end goal day by day is surely not the most efficient way to get the job done. You need small, independent tasks to accomplish one day at a time. You need user stories.
What is a user story?
The most basic definition of a user story is a description of a product feature from the perspective of the person requesting the features. This could be a customer, internal admin, or third party.
User stories should accomplish a succinct, clear description of a feature request. They are often written in this formula:
As a (type of user), I’d like (end goal) so that (reason for end goal).
This format answers three key questions:
- Who are we building this for?
- What are we building?
- What value does it bring, or why are we building it?
For example:
As a system admin, I’d like to view a current customer’s transaction history on their account so that I can reference this history in customer communication.
Or…
As a current customer of XYZ Corp., I’d like to receive an email after I make a purchase online so that I have purchase confirmation.
These user stories describe small, individual accomplishments that contribute to the larger end goal of product development. A developer is able to look at this individual user story and estimate how long this will take to accomplish, communicate that estimate with the project manager and any clients involved in the project to set expectations, and then get the story done, tested, and out the door.
For this reason, user stories also contribute to agile project development, where new product capabilities are constantly being released – there’s no “big reveal”, just continuous improvements for your end users. Clearly written, small user stories are key to successful agile development and happy customers (not to mention happy developers).
Who writes user stories?
When a development team is working on a project, there is generally some sort of project owner who is responsible for the writing and prioritizing of user stories. If you’re following Scrum guidelines, this is the Product Owner (PO), or you might call them a Product Manager.
This PO role writes the individual stories, but they are based on data and information they collect from outside roles: conversations with end users, focus groups, investors, and stakeholders. An experienced PO can interpret what others are asking for when they request features, and translate this into a user story that the development team can understand and accomplish.
What makes a good user story?
Writing a user story seems simple, right? It’s summing up a feature in a sentence, how hard could that be? If you’re new to writing stories or agile development, you’ll quickly learn it’s a little more difficult than it seems. It’s easy to make stories too large by using vague language. What starts as one small addition can snowball into a multiple week project if the story isn’t written precisely.
As a good rule of thumb, user stories should follow the INVEST acronym:
Independent: Stories should be freestanding and not dependent on other items.
Negotiable: Avoid strict rules, and allow the team freedom to adjust based on need and the situation at the time.
Valuable: The end result provides value to customers, users, or stakeholders.
Estimatable: Effort can be approximated to a reasonable extent.
Small: Large stories are difficult to plan and execute in a timely manner.
Testable: Someone outside the team should understand how to test the story before it is ever completed.
How should they be written?
While user stories are expected to be brief, they have to contain a certain amount of detail to be executed accurately.
To support the short description of the user story, there are additional components that provide detail. These are often called the “Acceptance Criteria” or “Conditions of Satisfaction” that the developer working on the user story follows. These details are included in user stories to guide developers and designers who are performing the work.
These acceptance criteria might include design specifications, or where the feature needs to be located within the product. For the user story examples above, here are some possible acceptance criteria.
As a system admin, I’d like to view a current customer’s transaction history on their account so that I can reference this history in customer communication.
Acceptance criteria:
- The transaction history is displayed in reverse chronological order
- The history includes dates
- The history includes individual purchase totals
- A summary of the transaction history displays total lifetime purchase amount
As a current customer of XYZ Corp., I’d like to receive an email after I make a purchase online so that I have purchase confirmation.
Acceptance criteria:
- The email is sent within three minutes of purchase completion
- The email is sent from our internal sales email address
- The email includes total purchase amount
- Links in the email include customer-specific click tracking strings
When is a user story complete?
User stories are generally supported by a team’s Definition of Done, which is a set of agreed-upon guidelines for development that the team follows on every user story. This definition includes all of the necessary steps for a story to be called “done”.
This definition might include testing on certain environments, inclusion and execution of unit tests, writing user documentation, or approval by the product owner. This definition of done ensures that a user story is potentially shippable when it’s marked done. Following through on user stories to this point helps prevent a big backlog of testing or design work, and keeps features rolling out more consistently.
This introduction to user stories should give you a better idea of what purpose stories serve for your product and team. If you aren’t using them in your product development, or you aren’t following an agile guideline, there are still lessons to be learned from user stories that can benefit your business.
Next week, a second post on user stories will be available that will highlight common mistakes in user story creation and how to avoid them. Trust me, you’ve probably made one or two of these mistakes before (we have, too). Stay tuned!
Resources for further reading
What is Scrum? An Agile Framework - Scrum Alliance
The Agile Product Manager - Atlassian
Agile User Stories - Scrum Alliance
Epics, stories, versions, and sprints - Atlassian
Video: Agile User Stories - Mark Shead