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, 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;
What is in a user story?
A user story should have these 3 items in it.
- who wants it?
- why do they want it?
- what do they want?
What makes a good user story?
Or, what makes a user story good? One that anchors team collaboration and discussion around the benefit of the functionality to the user needs, and clearly describes what is expected.
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 Style Guide
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.
What is a user story style guide?
A user story style guide is a set of rules and constraints that describe a way to consistently format user stories.
The user story style guide is made up of 3 parts;
- User Story Schema defines the content.
- User Story Format defines the formatting.
- 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
User Story Format
Story short title
Traditional form story title as description.
- bullet point acceptance criteria
- bullet point constraint
- 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.
- No text formatting. Except for bold title/summary.
- Use less text to say the same thing.
- 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.