As an Agile coach, I’m asked a lot of questions about writing user stories. At the top of the list: "how do I write a good user story?" and "Give me an example of a good user story." That second request is tricky, since what's good for one person might not make sense to another. But I'll tackle the first question here with some examples.
First of all, I highly recommend using the "value statement" template to write all user stories, features, and even high-level items like epics, where applicable. It's a quick and consistent way to get to the Who, What, and Why information:
As a [type of user], I want a [goal or feature], so I can [get benefit or outcome].
When Product Owners and Agile teams use this format, anyone can quickly skim the user story and confirm that the "who" (type of user), "what" (feature), and "why" (outcome) are all included, and not have to understand the full context of the user story to know if anything vital is missing. Frequently people do include the "who, what, and why" without using that format. That's okay; it just takes a bit more time to review the story.
But, even if you fill in the "who," "what," and "why," using the value statement format, that doesn't automatically make a good user story.
Here's a fictional user story breakdown, a composite of real exchanges that I've had with Agile teams and Product Owners.
The PO’s user story:
As a User I want a database to store the control index values.
That is a pretty terrible user story. Why?
First, "User" could be anyone. What kind of user?
Second, while a database is technically a "what," it heavily implies the "how" or implementation, which doesn’t belong in the value statement: it’s up to the team to determine. Stating "how" restricts the team and discourages them from creating innovative solutions. If there are specific requirements that restrict the "how", then that information should go in the user story's acceptance criteria, not the value statement.
Third, what is the business value in building a database to store control index values? What even is a control index? Do control indices make the company money? Are customers buying control indices? Can I buy a control index?
And fourth, most critically, it’s missing the third part of the value statement: the why.
This user story, to me, sounds like an API output or parameter, or some other type of technical thing, which doesn’t serve the purpose of a value statement. What’s great about value statements is that they describe the value to the customer of the work they ask for. Unless you’re designing for developers, end users don’t want APIs.
It's about now that my brain usually starts chanting "So I can, so I can…" and an old 80s pop song comes to mind:
Cory Hart's user story:
"As a cool guy, I wear my sunglasses at night, so I can keep track of the visions in my eyes."
Cory Hart gives a ton of reasons for wearing his sunglasses at night (including the weaving and breathing of story lines and forgetting his name while a claim is being collected). I don't know if there's a business value in "seeing the light that shines before my eyes," but you do get the sense that he's going somewhere with it. And at least it's catchy.
With those words in mind, let’s go to my conversation with the Product Owner:
Me:
This sounds vague and technical to me. It also describes the implementation, which we want to avoid in most user stories. Can you explain to me who the user is, what they want to store, and why they need it?
PO:
Okay, how about “As a site administrator, I want product ID data stored, so I can get it later.”
Okay, now we're making a little progress. This version follows the value statement template and there is a type of user! It's not an end user, but maybe this user story is a non-functional requirement (NFR) or enabler item (i.e. foundational work that doesn’t directly deliver business value, but needs to be done to unlock the user stories that do). I'm willing to give them the benefit of the doubt, but I wonder if there's a real customer-focused user story buried here somewhere.
Me:
What kind of products are we talking about, and why would you need to store those?
PO:
We need to store the customer’s purchase information safely, so only the authorized people can access it. How about “As a site administrator, I need user purchase information stored, so that I can control who accesses the information.”
Better, but the “so I can” is still unclear. Why does the administrator need to control who accesses the information? Maybe this is a security certification requirement—“need” instead of “want” implies that this is critical. But while certification requirements are very important, they don't usually create business value. So either this story’s an NFR, or this belongs in the story’s acceptance criteria and not in its value statement. Always start with the business value of the work.
Me:
This looks like a non-functional requirement to me. What actual end user would need this functionality?
PO:
Well, our customers want their information to be safe. How’s this? “As an online store customer, I want my purchase information stored, so I can know my information is secure.”
Okay, we've flipped the customer around: it’s an end user, which is moving in the right direction.
Now, it is important that data is secure, but “so I can know my info’s secure” still gives us no business value. Why are we storing the data in the first place? What’s going to be done with it? This Product Owner really wants to build some type of database, but they're still not really telling me why.
Me:
So, what does this generic "online store customer” want to do with their purchase information?
PO:
They want to see their data.
Me:
Which data?
PO:
All their data about all the products they've bought from our online store.
Me:
But that could be a lot of data, and that sounds like an epic or scenario. It's certainly not a single sprint's worth of work, which is the size a user story needs to be. Let's start by focusing on one type of data, on one platform, for one specific type of user.
PO:
Okay. “As a premium member, I want to see my purchase history so I can see what I've already bought.”
Hey, that's a real user story! But there’s still something there that’s bugging me. The “so I can” still feels light-weight to me.
Me:
Isn’t every user interested in seeing their purchase history? What makes premium members special here?
PO:
Because we provide premium members with additional services that require knowing their purchase history.
Me:
So then this work isn’t about showing the user their purchase history information, it’s about doing something with it.
PO:
But that step is still needed before we can provide the services. And it’s small enough to fit into one sprint.
The conversation continues in this manner until we finally boil it down to several user stories that may be part of an overall customer scenario. Here’s just one of them:
As a premium online customer, I want to see a list of suggested products based on products that I have already purchased and used, so that I can purchase more exciting and useful content like the products that I already love.
There’s a “so I can” we can get behind! Sure, there's probably a database back there somewhere, and it will have Product ID information in it. But compared to our original discussion, this story is something the customer cares about and it delivers clear business value.
At this point the Product Owner fills in the acceptance criteria (including any previous security concerns) and then shows the user story to the team in a Backlog Grooming meeting. The team sizes the story in the meeting. If it’s work that can be completed within one sprint, then it's put into the backlog. If it's too large, then it's broken down further (keeping the “so I can” in mind at every step), until each piece fits into a sprint. The team may also add non-functional user stories to the backlog (that may, indeed, look similar to that initial story) to enable the overall effort.
This user story may be part of a greater feature or scenario relating to the customer purchase data that may involve anything from site licenses and warranties to suggestion lists and coupons (with a “so I can” for every scenario). With clear and well understood scenarios and features, it’s also easier to break down the information into smaller user stories that the team can implement.
(And I totally have a pair of old shades just like Cory’s!)