A User Story Format for Better User Stories

This user story style guide idea came about around ten years ago. It was when I was looking to provide the developers I was leading with absolute clarity on what we agreed to do as a team for our product owner. I decided to share the user story style guide here as it may be helpful for others.

The trouble was that merely viewing the stories in the backlog had enough templating and formatting variances that it made it distracting and enough to make the activity sub-optimal. Even though there were templates and attempts to standardise a user story format within and across projects, there were still differences between how some user stories were composed. A fair amount of time was spent asking, "What did they mean?" or "Why is that bold? Is it more important?".

Everybody knew the basics of what makes a user story suitable, and we had alignment on such things as;

Something was missing, though. My teams had the above things. But we still had friction between what was written and consuming what was written across the group. The solution was a user story style guide to create consistency.

User Story Format

We devised a user story style guide that all current and future product and scrum team members could refer to easily create explicit user stories. Part of the user story grooming process was editing and formatting to meet the style guide rules. This user story style guide would describe the user story format.

The user story style guide is made up of 3 parts that describe the rules for a standard user story format;

1. User Story Schema defines the content.
2. User Story Format defines the formatting.
3. Example User Story demonstrates the usage of the schema and the format.

The result was not what we expected. Not only did we get consistently styled user stories, the effort spent considering the content of the stories also resulted in higher quality user stories with nearly zero ambiguity.

User Story Schema

<actors> can <goal>

As an <actor>, I want <goal> so that <reason>.

• User Ability

Constraints

• Limitation

Assumptions

• Assumption

User Story Format

Story short title

Traditional form story title as description.

• bullet point acceptance criteria

Constraints

• bullet point constraint

Assumptions

• bullet point assumption

Example User Story

Team members can write consistently formatted user stories

As a project team member, I want to rely on a style guide to help me consistently format user stories so that colleagues don't need to decipher formatting, codes, symbols, or language.

• The title is the story summary in the format of: <actors> can <goal>
• The description is the traditional story format of: As an <actor>, I want to <goal> so that <reason>.
• Acceptance criteria follow the description as a bullet list.
• Constraints and assumptions may follow as bullet lists.
• Headings and new lines may separate constraints and assumptions.
• Technical documentation, wireframes or designs should accompany.

Constraints

• No text formatting. Except for bold title/summary.
• Use less text to say the same thing.

Assumptions

• Stories are continually groomed.
• Title, description, acceptance criteria, assumptions, size, dependencies, risks, estimate, priority and tasks are set before starting.
• Changes to stories in progress are managed.

PDF Download for members

Please sign up to download a handy and attractive flyer set that outlines the information in this article.