A User Story Format for Better User Stories

This idea of a user story style guide came about as an idea around 10 years ago. It was when I was looking to provide the developers I was leading, with absolute clarity on what we were agreeing to do as a team for our product owner. I decided to share the user story style guide here as it may be useful for others to consider.

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 good, 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 team. The solution was a user story style guide to create consistency.

User Story Format

We came up with the idea of a user story style guide that all current and future product and scrum team members could refer to, to easily create clear user stories. Part of the user story grooming process became to edit and format 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 describes 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 member of a project team, 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 and symbols or language.

• Title is the story summary in the format of: <actors> can <goal>
• 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.
• Constraints and assumptions may be separated by headings and new lines.
• 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