This post is the first of a series on writing Agile User Stories and Requirements. This post explains the very basics of what a User Story is. In forthcoming posts, we will explore concepts such as the INVEST mnemonic and Given/When/Then Acceptance Criteria.

Though there are many flavors of Agile, one unifying concept is that of the UserStory. The UserStory itself is a simple concept, yet like the game of Othello, it takes “a minute to learn… and a lifetime to master”. If you want to be in the business of making great products, then learning to write great User Stories is well worth the effort.

In Agile, UserStories are the primary vehicle that translates new product or feature ideas into actionable work orders that can be prioritized and completed. Most commonly used in software development, the purpose of the UserStory is to request a new product feature in simple terms that are understandable to laymen, yet thorough enough for technical execution. The difference between good and bad User Stories can be the difference between launching on time and on budget – or not. However, with strong UserStories, teams can work more efficiently, accurately and transparently than ever.

UserStory Examples

The standard UserStory format is made up of three parts and usually follows the following script:

As a… (1: type of user), I want… (2: a something new), so that… (3: value is created)

Let’s break that down:

As a…

In the first part of the UserStory, the writer states the persona of who is speaking. This sets the stage for the person who will complete the work and informs them who will benefit from the work they are doing. Commonly, other details about the state of the user will be stated such as their state of mind or assumptions. For example, imagine, if you will, a Gorilla doing grocery shopping online: “As a hungry Gorilla...”

I want…

In the second part of the UserStory, the writer states what the user wants to be able to do. It is usually a new ability of the user, or a new behavior of the system (or combinations of both). It should be an observable instance of “cause and effect”. An example of this could be: “…I want to filter the produce list to only bananas…“

So that…

Finally, the “So that…” clause clarifies the end-goal of the writer, it explains what problem is being solved. It is critical that the person who is performing the work understands the motivation behind the work they are doing. By ensuring that the “why” is understood, the writer reduces ambiguity and ensures that the right problem is getting solved. Our example for this clause is: “…so that I quickly and easily find the foods I’m likely to purchase.

All together now:

“As a hungry Gorilla, I want to filter the produce list to only bananas, so that I quickly and easily find the foods I’m likely to purchase.”

Why writeUserStories?

Writinguserstories seems simple enough, but despite that, old habits or downright laziness can get in the way of such best practices. This can result in Product Owners writing product requirements that are crude, and/or derived from out-dated methods – at their own peril.

By using this standard format, your product requirements will have distinct advantages because your User Stories will be:

Understandable by all, and thus universally portable.

Bite-sized and easy to review, prioritize and update.

Consistently structured, which makes them easier to execute.

Totally Agile. Totes McGotes Agile.

For these reasons, I strongly encourage not just Product Owners, but anyone requesting a product feature, to learn the UserStory format, and to challenge themselves to continually master its nuances. For those at Gorilla Logic, it’s an everyday thing, like shopping for bananas online.

Josh is a Product Manager and Certified Scrum Product Owner® in Los Angeles, originally from Philadelphia (Philly). From bootstrapped start-ups to the biggest media companies in the world, Josh has extensive experience building successful products with distributed Agile teams. His hobbies include solving problems, building things and inspiring people.

Comments (1)

1 Comment

Katelyn Hasz on December 8, 2016 at 9:37 am

“As a UX student, I want more informative articles from Gorilla Logic, so that I graduate at the top of my class, with a fulfilling job and pay off my mounds of debt.”

Still working on it…thanks for the article! Writing user stories is harder than it would appear, but I will always keep in mind this great example of the hungry gorilla.