Stories get their name from how they should be used, not what should be written. – Jeff Patton
If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way. – Kent Beck
It’s easy to lose sight of the true intent of user stories.
As a product person you want to understand your customers needs. You want your product to satisfy those needs. You want to build a shared understanding of those things with your team. You want to build that shared understanding quickly so you can get stuff done.
No doubt when you were first introduced to user stories you were told writing user stories was the way to accomplish the above things.
You were skeptical. User stories are so short. How could they possibly convey all the information your team needs?
They can’t. And they weren’t intended to. Here are three key things you ought to know about writing user stories:
User stories are placeholders for a conversation.
User stories are intentionally brief and non descriptive.
They reinforce the idea that shared understanding of what you’re trying to build grows through the process of trying to build it. You can’t know everything up front.
User stories are reminders to have conversations about what you’re trying to help your product’s users and organization’s customers accomplish.
You’ll most likely need to remember what you talked about during those conversations. You can record that information when you describe your user stories.
User stories are a planning tool
User stories allow you to break up the work to build a product based on things your users can accomplish with the product.
That’s different than other ways of organizing work that were based on listing out the tasks you need to perform.
For example, if you wanted to create a membership site, some user stories might be:
- Create profile
- View profile
- Edit profile
- Delete profile
These are things that a user can accomplish with your membership site.
Contrast those items with a task based approach which might look like:
- Identify profile fields
- Design profile screen
- Design profile table
- Build profile screen
- Build profile table in database
- Create new profile record in profile table
- Update profile record in profile table
- Delete profile record from profile table
The work you end up doing in both situations is the same, but organizing the work by user stories groups the work together in a way that allows you to get rapid feedback as soon as possible.
You could start with Create profile and once you’ve delivered that you can get meaningful feedback on whether you’re collecting the right information for a profile. You could even release that to your users and allow people to start signing up.
When you organize your work by tasks, you effectively assume that you know everything you need to do upfront (you don’t) and you can easily lose sight of ways to get intermediate feedback on how your solution is coming together.
You still eventually do the tasks I listed in the second example, but you identify them right before you start working on the particular user story, and you only do the tasks you need to do to allow the user to accomplish that particular thing.
User stories help you decide which problems you are going to use your product to solve and in what order you are going to solve those problems.
User stories also help you get to details in a just in time fashion so you can be as informed as possible when you dive into the deep details of a particular bit of work. You don’t have to pull together a bunch of information too early – only to find out the assumption you made were wrong, or you don’t need to solve a particular aspect of the problem.
When you use cards to represent your user stories – whether they are actual cards, or virtual ones – you have something you can move around while you’re talking about what you will and won’t do. That visual cue can help your team build a shared understanding and keep focused on the part of the product you’re going to create or change in the next week or two.
It’s not the writing that’s important
Since the intent for user stories was never to be a reminder to communicate further, not the means of communication, how the story is written becomes less important.
That’s not to say that the information you know about a story is not important, you don’t have to be overly pedantic about writing stories in a very specific way.
You want to make sure your team is clear about who the story impacts, what they want to do and why, but that does not immediately mean that you have to write everything in terms of “As A, I Want, So That”
And just because I said you don’t have to do that, doesn’t mean that you shouldn’t use the format at all. As a, I want, So That is a great reminder to identify the who, what, and why. If you need that reminder.
Have trouble pinning down the why? Perhaps you should use the format In Order to (Why) As A (Who) I want (What).
Do you find that the nature of who uses your product is based more on what they are trying to accomplish rather than who they are, perhaps a context specific format (aka Job Stories) is more helpful: When (Situation), I want to (Motivation), so I can (Expected Outcome) .
When I put together the backlog for the Submission System, I usually provide a short title for the user story then provide a longer description where I may sometimes use one of the above formats, if I find it helpful.
For example a current item on the Submission System backlog is:
Title: Indicate sessions where submitter has responded
Short Description: As a reviewer I want to know on which sessions a submitter has responded to my feedback since I last viewed the session so that I know which sessions to go back and view for changes.
You may or may not understand all of that, and that’s ok.
As long as your user story has enough information to remind your team what the intent is, and you have somewhere to note any additional information that comes about as a result of the discussions about the story, that’s sufficient, regardless of format.
What that information actually is varies by team, and can often be described in terms of a definition of ready.
In this week’s Inside Product Management, I share a set of resources that cover the key aspects of user stories. These ideas have been around awhile. They still hold true, and they are often the things that people forget when they start getting obsessed about whether they’ve written the user story in the correct way.
User Story Overview
The Agile Alliance glossary item on user stories provides insight into the origins of user stories, how an understanding of the concept refined over time, and signs of use of user stories at both an individual and team level.
User Story Format
This Agile Alliance glossary item explores the most common format for user stories:
- As a (Who)
- I want (What)
- So That (Why).
Referred to in the glossary entry as Role – Feature – Reason.
Each of those characteristics is linked to an article that Bill wrote specifically addressing each characteristic.
Card, Conversation Confirmation
The 3 C’s (Card, Conversation, Confirmation) originally coined by Ron Jeffries, helps you remember the three key components of user stories, and reinforces that the written aspect of the user story is only a small part of the story.
50 Quick Ideas to Improve Your User Stories
If you want a collection of tips to improve your use of user stories (without getting pedantic about how you write them, which is the first tip) you’ll want to pick up a copy of Gojko Adzic’s book 50 Quick Ideas to Improve Your User Stories. (Affiliate link)
Thanks again for subscribing to Inside Product Management.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.
Talk to you next week,
Kent J. McDonald