How to Write Agile User Stories

---

Though there are many flavors of Agile, one unifying concept is that of the User Story. The User Story 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, User Stories 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 User Story 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 User Stories, teams can work more efficiently, accurately and transparently than ever.

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

Let’s break that down:

In the first part of the User Story, 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...”

In the second part of the User Story, 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…“

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:

Writing user stories 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 User Story 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.