User Stories Made Simple
Published on Feb 08, 2018
How well do you know who you’re building for? A formal process of user story development is great for anyone, from solopreneurs to large distributed teams, to have a clear idea of what problems they’re trying to solve. In this talk, I will outline the steps you should take to create clear, actionable user stories, and avoid pitfalls that can derail your project.
This was presented at WordCamp Phoenix 2018
MORE DECKS TO EXPLORE
PRESENTATION OUTLINE
Untitled Slide
Does this look familiar?
Anyone who's built a website knows the importance of keeping track of all the things that need to be done. Not only does this ensure that you won't forget something important, but it also allows your client to see what's being worked on and what's been completed. Keeping track of tasks is necessary for accountability.
But a project is much more than the sum of its tasks. It's possible to get all the way through each individual task and end up with something your client and their users hate and can't use.
There's a different way. User stories let you encapsulate the what along with the context of why, ensuring you build the right thing for the right person.
Anyone who's built a website knows the importance of keeping track of all the things that need to be done. Not only does this ensure that you won't forget something important, but it also allows your client to see what's being worked on and what's been completed. Keeping track of tasks is necessary for accountability.
But a project is much more than the sum of its tasks. It's possible to get all the way through each individual task and end up with something your client and their users hate and can't use.
There's a different way. User stories let you encapsulate the what along with the context of why, ensuring you build the right thing for the right person.
Objectives
- Learn more about product thinking to understand your user's needs
- Write clear, manageable user stories that keep your team on track
Here's what I hope you'll learn from this presentation.
Photo by Jasper van der Meij
Assumptions
- You use an Agile process
- You have more than one person, and more than one functional role on your team
Here's what I've assumed about your team when I wrote this (always keep that end user in mind, right?).
If this doesn't entirely describe your team, let's address how this process can be modified for your team during our Q&A time.
If this doesn't entirely describe your team, let's address how this process can be modified for your team during our Q&A time.
Photo by kenny barker
What you need
- User personas
- Your team
- A project objective that will take several sprints to achieve
Consider this your grocery list for sitting down to write user stories.
We'll talk about user personas in more detail in just a moment, but in the meantime, let's touch on teams and objectives.
We'll talk about user personas in more detail in just a moment, but in the meantime, let's touch on teams and objectives.
Photo by bibendum84
Who's on your team?
- Technical writers
- Testers
- Programmers
- Designers
- Database architects
- Analysts
These are just some of the functional roles that your team might represent.
Larger Agile teams may have multiple people fulfilling each role. Smaller teams might have some people wearing multiple hats.
This is but an example of some of the dimensions to keep in mind. A website build might not have much use for technical writers, but a software team writing documentation for the end user would. You might not need a database architect unless you're getting real weird with the WordPress architecture so you can index tables that aren't usually indexed.
Larger Agile teams may have multiple people fulfilling each role. Smaller teams might have some people wearing multiple hats.
This is but an example of some of the dimensions to keep in mind. A website build might not have much use for technical writers, but a software team writing documentation for the end user would. You might not need a database architect unless you're getting real weird with the WordPress architecture so you can index tables that aren't usually indexed.
Photo by kuwait kites team
“Co-creating something is one of the best ways of establishing an aligned vision for a product.”
– Mountain Goat Software
Especially with busy projects, it's tempting to let the developers and designers just keep grinding to make deadlines.
Try to resist the urge to keep your story writing meetings just to the product or project manager and stakeholders.
When the devs and designers have a hand in discussing and crafting user stories, you ensure that the entire team is on the same page and working towards the right set of goals.
Just because a project stage doesn't involve producing lines of code doesn't mean you don't need your coders involved.
Everyone needs to have a strong understanding of who the user is in order to perform their function on the team.
We use user personas to help define the user.
Try to resist the urge to keep your story writing meetings just to the product or project manager and stakeholders.
When the devs and designers have a hand in discussing and crafting user stories, you ensure that the entire team is on the same page and working towards the right set of goals.
Just because a project stage doesn't involve producing lines of code doesn't mean you don't need your coders involved.
Everyone needs to have a strong understanding of who the user is in order to perform their function on the team.
We use user personas to help define the user.
Photo by Thomas Hawk
User personas
- Represent your product's core demographic(s)
- Describes what your user does, *without* consideration of how they use your product
Writing user personas is a great exercise in understanding the needs and wants of the humans who will eventually use the website or app you're creating.
The most important part may seem to be against logic: your product should not be a consideration in your personas.
Think about it this way: when you're trying to solve someone's problem, you have to understand what that problem is before you can even attempt to fix it.
No one likes when you tell someone about a problem you have and they're so busy trying to fix it for you, they stop listening to what you say. The solution they come up with almost aways leaves out important considerations. Your solution is no solution at all if no one can use it.
Here's an example of what I mean:
The most important part may seem to be against logic: your product should not be a consideration in your personas.
Think about it this way: when you're trying to solve someone's problem, you have to understand what that problem is before you can even attempt to fix it.
No one likes when you tell someone about a problem you have and they're so busy trying to fix it for you, they stop listening to what you say. The solution they come up with almost aways leaves out important considerations. Your solution is no solution at all if no one can use it.
Here's an example of what I mean:
Photo by Victoria Nevland
Julie (city clerk, 42) spends her day fielding document requests from her city's residents. She wishes there were two or three of her, but cloning isn't real yet.
This is just an example I wrote for this presentation of an opening line to a user persona. It identifies who the user is, giving them a name (in this case, Julie), what their work function is (city clerk), how old they are (42), what they do (public interaction and requests), and the main obstacle (not enough people to get the job done).
Giving your user a name, age, and other identifying marks is a useful technique to make your personas more real in your planning room. It's an interface to help us empathize with what this type of user faces.
It's rare that you might have only one user persona. I've worked on projects with 5 or more personas, each with unique wants and needs.
This empathizing exercise can pay off in unexpected ways. Once, I uncovered a security concern we had to address, just by thinking about what a particular user would look for when evaluating a particular product.
So, once we understand who our user is and what they need, we can start writing user stories for the team to work from.
Giving your user a name, age, and other identifying marks is a useful technique to make your personas more real in your planning room. It's an interface to help us empathize with what this type of user faces.
It's rare that you might have only one user persona. I've worked on projects with 5 or more personas, each with unique wants and needs.
This empathizing exercise can pay off in unexpected ways. Once, I uncovered a security concern we had to address, just by thinking about what a particular user would look for when evaluating a particular product.
So, once we understand who our user is and what they need, we can start writing user stories for the team to work from.
Photo by sdstrowes
User stories answer these ?s
- What does the user need to do?
- Why do they need to do it?
- What's getting in their way?
Using our previous example, Julie needs to answer document requests from the general public. Let's say it's a legal requirement that these documents are available by request, so there's no getting around it - the requests must be fulfilled.
The limits of time and space are getting in Julie the City Clerk's way. There are too many requests for her to handle in a single 8 hour shift. If requests take too long, people grow impatient. Perhaps some people start to wonder if there's a conspiracy to prevent them from accessing the documents.
A transparent, quick process would help ensure that a secondary problem can be addressed -- number of angry follow-up phone calls and office visits.
There are clear stakes in this game. Now we have a good problem worth solving.
The limits of time and space are getting in Julie the City Clerk's way. There are too many requests for her to handle in a single 8 hour shift. If requests take too long, people grow impatient. Perhaps some people start to wonder if there's a conspiracy to prevent them from accessing the documents.
A transparent, quick process would help ensure that a secondary problem can be addressed -- number of angry follow-up phone calls and office visits.
There are clear stakes in this game. Now we have a good problem worth solving.
Photo by David Travis
A user story describes how a product solves a person's problem.
It helps the user do something, or do something better
Our sample user story tells us our city clerk's problem - she's working long hours to try to avoid making requesters mad, because public document requests are too numerous for her to handle. Perhaps she's missing out on dinner with her partner and kids because of it. So, solving this problem could be a big win.
A product feature to help her could be a way to automate document simple requests so she only has to intervene for complicated things.
A product feature to help her could be a way to automate document simple requests so she only has to intervene for complicated things.
Photo by jakuza
As a ____, I want to ____ so I can ____
This is a basic framework for your stories to make sure you're always filling in the blanks.
Using the example from the last slide, one user story could be "As a city clerk, I want to handle public document requests more efficiently so I stop getting angry phone calls, and I don't have to work so much overtime."
Now, this story is a bit large and a little vague but that's a matter for later in the presentation. For now, this works as a basic example.
Using the example from the last slide, one user story could be "As a city clerk, I want to handle public document requests more efficiently so I stop getting angry phone calls, and I don't have to work so much overtime."
Now, this story is a bit large and a little vague but that's a matter for later in the presentation. For now, this works as a basic example.
Photo by psd
No one cares how you built it
They want to know what it can do for them
I want to call attention to how none of the documentation up to this point has made any mention of code libraries, content management systems, web hosts, or any other piece of technology.
The end user doesn't care what cool new JavaScript library you're leveraging. They don't care that you're deploying Elasticsearch to supercharge your WordPress install's searchability. They care that when they search, they can find the content they want - even if the search query contains misspelled words.
Try to avoid the urge to impress your client with a bunch of technological jargon they don't understand. This doesn't inspire confidence in your abilities. Tell them how their life will be easier because of the solution you are building.
(Though, of course, if you need to get technical to justify your healthy invoice size, by all means have that conversation! But, people sign on the dotted line for solutions, not technology.)
The end user doesn't care what cool new JavaScript library you're leveraging. They don't care that you're deploying Elasticsearch to supercharge your WordPress install's searchability. They care that when they search, they can find the content they want - even if the search query contains misspelled words.
Try to avoid the urge to impress your client with a bunch of technological jargon they don't understand. This doesn't inspire confidence in your abilities. Tell them how their life will be easier because of the solution you are building.
(Though, of course, if you need to get technical to justify your healthy invoice size, by all means have that conversation! But, people sign on the dotted line for solutions, not technology.)
Photo by Sutha Kamal
How does this feature make someone better at their job?
Success is not the size of the invoice the project generated (though of course, those help!). It's not even completing your task list.
Someone else's success using the tool you created is a vital measurement of your own success. As mentioned previously, the solution you create is no solution at all if it doesn't improve someone's specific problem.
Keep this in mind always. Can you make your end user look like a rock star? Can they scale tall buildings in a single bound? Can they get everything done so they can go home in time to have dinner with their kids every day?
Success needs to be defined and measured so you know how you're doing.
Someone else's success using the tool you created is a vital measurement of your own success. As mentioned previously, the solution you create is no solution at all if it doesn't improve someone's specific problem.
Keep this in mind always. Can you make your end user look like a rock star? Can they scale tall buildings in a single bound? Can they get everything done so they can go home in time to have dinner with their kids every day?
Success needs to be defined and measured so you know how you're doing.
Photo by wili_hybrid
SMART goals
- Specific
- Measurable
- Achievable
- Relevant
- Time bound
Goals need to be SMARTer than "make more money," "save more time," and "do more with less." Those are fine as aspirations, but in order for it to be a goal, it has to be defined. In most sports, you can't just lob a ball blindly in the general direction of where you think the goal is -- you have to throw or kick or run with precision to a specific, pre-defined consensus place for it to count.
You want to make more money? How about $10,000 more in gross revenue this month instead, or reduce the need for overtime hours by 50% this quarter.
You want to make more money? How about $10,000 more in gross revenue this month instead, or reduce the need for overtime hours by 50% this quarter.
Photo by carnagenyc
measure MEANINGFUL KPI'S
- Shopping cart abandonment rate over time
- Average order value over time
- Qualified leads per month
- Can be different depending on business goals
KPIs are Key Performance Indicators. These are just a few examples of dimensions that can be measured. The right KPIs for your project will likely vary considerably from these, but these are a jumping off point.
Note the specificity, and the time boxing.
Note the specificity, and the time boxing.
Photo by Ben (Falcifer)
The Process
- High value business goal (Agile epic)
- Job task user story (Product backlog)
- Product user story (Sprint backlog)
- Developer / Designer task
Here's how all the pieces we've discussed fit into a hierarchy. Your SMART goal might need several features to satisfy it, and these user stories like our example of Julie the City Clerk earlier will make up your product backlog.
But this is Agile, and we work in sprints. You could spend your entire quarter trying to make it easier for Julie to get home to her kids in time for dinner.
You want to split your big stories out into smaller, sprint-sized bites so you can measure velocity - how many story points your team can deliver in a period of time, so that you can measure how much work you can deliver against your deadline.
But this is Agile, and we work in sprints. You could spend your entire quarter trying to make it easier for Julie to get home to her kids in time for dinner.
You want to split your big stories out into smaller, sprint-sized bites so you can measure velocity - how many story points your team can deliver in a period of time, so that you can measure how much work you can deliver against your deadline.
Photo by Lost Tulsa
MVP – Minimum Viable Product that could take several iterations to ship
It's been said that there's no such thing as a finished project, and there are only products that we've decided to ship no matter how much we might cringe doing it.
Defining your MVP means defining what will ship, so that when you hit the threshold, you know you can go to market.
This should take your team several sprints to accomplish.
Defining your MVP means defining what will ship, so that when you hit the threshold, you know you can go to market.
This should take your team several sprints to accomplish.
Photo by John Torcasio
MMF – Minimum Marketable Feature, a set of features that represent enough of what users need to be valuable to them
Once you've shipped your MVP, future releases might represent an MMF -- a chunk of functionality that represents the minimum usefulness for the end user in order for it to be noteworthy for them. These features may not be enough to stand on their own, but they make meaningful improvements to the existing product.
Photo by slworking2
Cadence
- Once per phase for phased projects
- Once per quarter for software
This is a process, so you won't get all the user stories you need in just one meeting. You should have a story writing workshop once per quarter for ongoing builds, or once per phase for a phased project.
This ensures that your team can stay Agile by not getting bogged down by too much documentation. You want just the right amount of documentation at the right time.
This ensures that your team can stay Agile by not getting bogged down by too much documentation. You want just the right amount of documentation at the right time.
Photo by Nick Bramhall
Other topics in user stories
- Splitting user stories (SPIDR)
- Story mapping
There are a couple topics I didn't have room for in this talk - splitting stories, and story mapping.
Splitting stories is how you take a larger, more general product backlog item and turn it into something sprint-sized that your team can complete in just one sprint.
You can use the SPIDR method to split: Spike, Path, Interface, Data, Rules.
Spike - a period of research/discovery needed before work can be done
Paths - "pay with credit card" and "pay with cash" can be two different stories, because they're two payment paths the user needs
Interface - Web, iOS, Android can each be separate stories
Data - Separate stories for chunks of the data. Instead of working with data from an entire country, you could split it up state by state.
Rules - If it's more work to limit access to a part of the product by membership, have your initial story make the info available to all, and a subsequent release limit by access rules
Story mapping is a technique to visualize the actions a user will take on your website, app, or software. You can use the map to split your stories into future phased builds, and see clearly what your MVP might look like.
Splitting stories is how you take a larger, more general product backlog item and turn it into something sprint-sized that your team can complete in just one sprint.
You can use the SPIDR method to split: Spike, Path, Interface, Data, Rules.
Spike - a period of research/discovery needed before work can be done
Paths - "pay with credit card" and "pay with cash" can be two different stories, because they're two payment paths the user needs
Interface - Web, iOS, Android can each be separate stories
Data - Separate stories for chunks of the data. Instead of working with data from an entire country, you could split it up state by state.
Rules - If it's more work to limit access to a part of the product by membership, have your initial story make the info available to all, and a subsequent release limit by access rules
Story mapping is a technique to visualize the actions a user will take on your website, app, or software. You can use the map to split your stories into future phased builds, and see clearly what your MVP might look like.
Photo by michaelvit
References
- Mountain Goat Software's "Better User Stories" video series: mountaingoatsoftware.com/training/courses/better-user-stories
- Orange County Product Managers meetup
These are some of the references I used writing these presentation.
There's no way to learn quite like doing it though, so I encourage you to get out to a professional meetup and talk to others doing the work!
There's no way to learn quite like doing it though, so I encourage you to get out to a professional meetup and talk to others doing the work!
Photo by Barbara L. Slavin
