Better backlogs, part 2: Stick to the problem space

Jerry Jäppinen
Nov 14, 2016 · 5 min read

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

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 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

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

Writing down the obvious

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

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 🖖

Lateral Nord

Writings from Lateral Nord on design, technology and…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store