The 4 crucial elements to writing killer user stories for “WOW” products
One of them is overlooked most of the time
User stories done wrong.
What I learned early on when I started out as product manager was that the main tool to get stuff built are “user stories”. The description of a feature in story form is helpful when communicating with development, no doubt. But what no one initially told me was that the common understanding of user stories is fundamentally flawed.
Across many sources you will encounter the same list of 3 core elements for user stories. However based on my recent experience in software projects — I would like to share an adoption of the method. One that has proven to produce superior results and contribute to the results of the executing team.
Preparations
Preparing for you user stories workshop, you have already identified customer personas and have them cooperate in writing the stories. A great article on writing good user stories is this one.
Your customer
As ___ …
I have seen many user stories that start out with “as a user…”. When you encounter one of those please send it straight to the bin. A “user” is a blank persona, lifeless and unsuited for breating life into your stories.
Instead point out your customer in that scenario: Don’t focus too much on pressing a predefined role into the story. But rather formulate the need or job the customer faces and which drives this story:
i.e. “As someone who is short on time and needs to make a last-minute flight booking for a business trip…”
Her problem
… I want to ___ …
Traditionally user stories that start out with “as a user…” continue with listing a feature that might be on a customers wishlist. Really this is already prematurely defining a technical solution. But that is really something you’ll want to leave to your engineers to figure out after you wrote your killer user story.
Instead of specifying the solution, think about the problem your customer is facing and not how your customer would solve that by selecting an entry in a list or pressing the pink button.
i.e. “… I don’t want to spend time on comparing detailed flight times and prices …”
The main goal
… so that ___ …
Now to the juicy part: What does your customer in that story expect? What are his goals, what is the value she is craving? Go ahead and really try to make it tangible for your team.
i.e. “… so that I can save time and go back to my work all while making sure that I get the best price for my preferred dates …”
The qualifier
… ___ times faster/cheaper/___ than in the current solution of ___.
The criterion often missed when pulling together user stories is the qualifier. How would you know that the story you formulated is ultimately helpful to your customer? How do you measure the importance and impact of the scenario?
When you add a qualifier like “it should be at least twice as fast” (as the current solution) or “I can save around $10 per booking” you suddenly have:
- A measure to use during validity checks of your story: “do $10 savings per booking make a real difference to you?”
- A measure to qualify technical solutions to the stated problem: “We made that process faster — on average from 10 minutes to 9 minutes. Is the story fulfilled?”
- A measure whether your business case is under- or overfulfilled.
Quite a powerful arsenal to make your work quantifiable, wouldn’t you say?
So, my recommendation: Always include a comparison or qualifier in the goal, something you might be later able to measure against.
With this setup you’ll be able to
- Decide on the worth, importance and urgency of the proposed solution. That makes prioritization in the product backlog a breeze.
- Define a measure and use it to determine when the story is done.
- Prevent scope creep: Do exactly as specified in the story, no over- or under-engineering.
But please remember:
- User stories are not a magic wand: it’s about the implementation team
- User stories have the risk of relying on too many assumptions, especially when working on a new product. To counter that, another favorite method of mine is that of “Jobs to be Done”.
Daniel Sontag connects the bots: As Industry 4.0 lead and manager for connected products, he does what he loves — tying business to tech, and theory to practice.
Hi, great you enjoyed the article! Feel free to give the applause button a few good clicks or leave a short response below, thanks.
Stay tuned: On Jumpstart-PM, The Industry 4.0 Blog and on LinkedIn
