• Product Owner

Here’s how to make sure User Stories are clear

User stories are a tool to describe desires for a product in a concise way, while also immediately outlining the context. A good User Story includes who the desired functionality is for, what this functionality is and what value it provides to the user. The User Story does not describe the solution – the how. The function of a User Story is to provide enough information of the desire to start a dialogue and facilitate the elaboration of the desire. An “invitation to a conversation.”

A common format for writing user stories is:

As [type of user]
I want [desired functionality]
So that [expected value]

Using this format, you quickly describe who, what and why you want to create something for. Let’s look at an example:

As a website visitor interested in a training course
I want a cool impression of the training
So that I want to book it without hesitation

and:

As a customer in the ordering process
I want to be able to specify an alternative delivery location
So that I can pick up my order at my time

Acceptance criteria

Well-defined user stories also tell you how you know that what you have created has actually fulfilled the user’s desire. Usually this takes the form of acceptance criteria or a “how to demo” statement. For example, acceptance criteria can be included as simply a list of criteria. For the first User Story example above, this could be:

• I see a video of the earlier participants touting the training
• I see inspiring pictures of the training room
• I read testimonials from enthusiastic participants who have taken the training before
• I read examples about the practical applications I learn

A common alternative to a list of acceptance criteria is the Given-When-Then (GWT) format, which describes more context. It describes for a scenario the input situation (Given/Given), the action or event (When/When), and the outcome (Then/Dan). Thus:

Given [input situation]
When [event]
Then [outcome]

Let’s elaborate on these using the User Story of the alternative delivery location from above:

Given the customer is in the ordering process
When is asked for the address of the location to be delivered to
Then the customer has the option of providing an address other than his home address

A User Story can contain multiple scenarios described in the GWT format. In this way, the desired behavior of the User Story can be described very concretely.

Note that a User Story is a vehicle for effective collaboration and elaboration of user requirements. It is not durable documentation; when the User Story is finished, it disappears. If you do need documentation – for example, a manual – capture it in an acceptance criterion or make it part of your Definition of Done.