Better backlogs, part 2: Stick to the problem space
I’ve worked with user stories a lot, written some but consumed much more as a product designer in agile teams. I think good user stories describe the needs of our end-users and the desired impact of the features we’re delivering to them.
User stories are very easy to write in a way that doesn’t really capture the motivations behind the work we put into our products. A product backlog should not be a todo list, and a story is not a task — yet that’s exactly what many people see when they open JIRA.
To put it shortly, what you should keep in mind is:
Stick to the problem space! I wrote about problems and solutions on a more abstract level in my product backlog intro post, and there are other great posts about this to read as well. The issue is similar to the XY problem many engineers face on Stack Overflow.
Let’s have a look at a real-life example of what this problem looks like and how you can reverse-engineer a task and create a user story instead!
Real-life example
There’s hundreds of blog posts out there with essentially the same example, but let’s recap just to illustrate a point.
Let’s take a web product. We have a flow where, users who try to book a trip on an e-commerce product aren’t taken to the payment page directly but for technical reasons are redirected via an intermediate page that’s called a transfer page.
Title: Suppress mobile web transfer page
Description: Showing the native overlay until the booking page is loaded.
Well, let’s start with the obvious: the format is wrong. I shouldn’t have to say this. Let’s try again.
Description: As a user I want to be shown the native overlay until the booking page is loaded.
Following a standard format makes things easier to read. The so that part is left out though, which is often the case, so the desired impact is not documented. Let’s try again.
Description: As a user I want to be shown the native overlay until the booking page is loaded so that I don’t see the mobile web transfer page.
Is this better? Not much: we’re being more explicit, but not really adding new information.
The key issue here is that we’re not describing user needs at all, just stating a thing that we should implement. There’s no explanation as to why and for whom we’re doing this. Let’s ask:
What’s the problem we’re trying to solve?
- Is the transfer page ugly?
- Is the waiting time too long?
- Is there poor communication about the system status?
- What’s so great about native overlays?
We can make a native loader, but how can a designer make decisions about look and behaviour when the problem isn’t communicated? Should we even be doing this, or should another team upgrade the systems so that the transfer page isn’t needed? These questions probably have answers, but the answers aren’t communicated. Let’s make this better.
From non-story to user story
When I get a non-story like this, I have to reverse engineer it and try to understand the motivation of the person writing the story (often by interviewing them) and figure out the problem they’re really interested in solving. Often it turns out that there’s more than one problem, leading us to split the story into multiple smaller ones so we can solve one at a time.
After researching this particular issue, the real issue seemed to be that the transitioning process was unnecessarily complicated and long. Or rather — this is our assumption, which we will A/B test once our developers are done with the story. Let’s try again.
As a user who wants to book a trip, I want to see the booking form as fast as possible after pressing the book button, without intermediate steps that feel unnecessary, so that I know the system is working correctly and I don’t drop out in frustration.
Not exactly a revelation, and a little vague, but looking at the situation from this perspective, we really have the broad set of potential solutions in our disposal, not limited to the native overlay that the writer happened to have in mind. When the problem is written down, we can much better evaluate or even measure which ideas would perform better and proceed with those.
Solution
In this example, a native overlay was easy to think of and something that the writer associated with a smooth process, which is quite understandable. But after interviewing the writer, researching various solutions and looking what other teams were doing, we found a way of removing the intermediate step completely and not having to introduce any additional loading indicators to the flow. Sometimes the work of a designer is to push hard to not do anything at all.
Writing down the obvious
If you look closely at the first version, there’s even the telltale sign of a definite article: the writer talks about the native overlay, referencing something that has been talked about before and assumes everyone knows about.
In real life, team members carry dozens, hundreds of feature ideas and implementation details in their head at any given time, and context switch like crazy throughout their work days. Expecting anyone to be able to come back to pick up a story with perfect recollection of everything that surrounds the topic is unrealistic — even if they haven’t been sick, on vacation, working remotely, having a cup of coffee or working with their headphones on during any of the several unregulated discussions that lead to the abstract requirements the writer assumes everyone has understood.
Acceptance criteria
I’ve ignored acceptance criteria here to keep this article short, but generally the same logic applies to them as well. They should absolutely be included though, otherwise it’s hard to know when a story is done done. I might come back to that later.
In this series of posts I’ll share some tips for avoiding common mistakes with your user stories and product backlog — especially those with a negative effect on design process or end-user experience. If you didn’t catch my first introduction post, you should start there!
You can read more about my work as a product designer and developer on my site at jerryjappinen.com or follow me on Twitter. Thanks for reading 🖖
