Create better user stories with a user story style guide. Consistently format user stories, without need to decipher formatting, codes and symbols or language.
This idea of a user story style guide came about as an idea around 10years ago. It was when I was looking to provide the developers I was leading, 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 imporant?".
Everybody knew the basics of what makes a user story good, and we had alignemnt on such things as;
Which 3 elements should a user story have?
- who wants it?
- what do they want?
- why do they want it?
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 use
Something was missing though. We still had friction between what was written, and consuming what was written across the team. The solution:
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.
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 amiguity.
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.
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 follows description as a bullet list.
- Constrains 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.