Template and guiding principles for writing good user stories.
Template and guiding principles for writing good user stories.
If you’re a product manager working in Agile with a product team comprised of developers, designers, etc. you’re probably spending time writing user stories into Trello, Jira, Asana, or on Post-It Notes. But what does a good user story look like?
What is a user story?
User story (a.k.a story card) is a way to describe the value of a product or feature for a specific role (i.e., user). Its use of simple language helps articulate a concept and create space for shared discovery and development of the requirements. While a user story is often treated as requirements, this is a big misnomer. Instead, user stories are meant to help start conversations quickly, so people can work together to discuss, discovery, define, and document detail requirements.
How to write an user story
Give each user story a name
Fill in using the Connextra template: As a <user/role> I want <service/product/feature>, so that <receive benefit>
Categorize the story as either an story or spike (i.e., for investigation/exploration
Define your acceptance criteria(s) (i.e., definitions of done) using behavior-driven-development format of Given, When, Then.
Sample User Story Template | Example User Story
User story works well when you’re working with a group of people who are willing and able to collaborate together in defining a shared understanding and solution. This requires a stable, mature, and experienced group of individuals with different skills, who can disagree on ideas versus personalities, hold each other’s perspectives, find compromises and common understanding, and are stable in duration (working together for more than 1 month). But that’s not always the case.
Principles for Good User Stories When Working with Less Mature Teams
More preparation work before the first conversation. Examples include:
If there are UI or visual element, create a rough sketch using Balsamiq or pencil & paper
Create a use case via a user flow diagram to help individuals understand the proposed user interaction over time via Lucidcharts or diagrams.net
Define the known constraints: time, resources (people, tools), limitations (process, legal, regulations, brand, etc.)
Define more detailed acceptance criteria by thinking about functional (what it will do) and non-functional (what it shall be) needs
Come with a solution(s), but be open to change. Use this technique to solicit input, but recognize the solution you start the conversation isn’t the end goal. [Note: While this may go against the principles of a user story, which is to solicit conversation to develop a shared understanding of detailed requirements, it can sometimes be hard to start the conversation. It’s easier for people to critique a solution, as one way to contribute in defining a shared understanding.]
Shorter and more frequent product backlog grooming discussions. Instead of 1 hour every 2 weeks, make it 30 minutes every other day.
Principles for Good User Stories When Working with Mature, Agile Teams
Keep it simple and use the user story to state intention, not a solution.
When holding conversations, encourage everyone to take turns as a scribe.
Allow others to write user stories, who aren’t product managers or owners.
Check your user story against the INVEST mnemonic, which mean’s
independent from other user stories in that you can consider the work done when one story is complete, but not dependent on another story
negotiable so that after a discussion and shared discovery / development, you can discard the user story
valuable to the user and not to the highest paid person’s opinion
estimable by people who will develop the software with a reasonable level of confidence (via time or points); otherwise more investigative work (i.e., spikes) should be started fart
small so it is estimable but also can be completed in a shorter time frames,
testable because people have understand the definition of done
Source:
INVEST mnemonic