Product backlog: Introduction

Jerry Jäppinen
Sep 26, 2016 · 6 min read

I work in a sizeable software company — one that’s sizeable after a fast growth sprint. Our headcount has gone from 0 to 180 in under four years. Product development practices need to scale in parallel, and we’re making a big push towards adopting agile practices.

Now, I’ve worked with agile customer projects and internal agile teams for a large portion of my work history, and I share my experiences and perspective as a designer quite often to the people and teams I work with. I don’t work as a product manager or a PO, but still the biggest and most frequent question that I find myself finding answers for is:

What are good user stories like in a product backlog?

Let’s start looking for answers.


Problems and solutions

A product backlog should quickly communicate the direction of a product and its upcoming features. Well, not just the features, but the benefit its end-users will get from it with every release. User stories are a way of documenting this information in a standardised, if a little bit vague format that most people working in the software industry today are familiar with.

Product backlog is a prioritised list of these stories. A user story should describe user needs, business needs and the general problem space so that every developer can use this insight when making small decisions in their implementation.

Solving a big problem is often done by breaking it down to multiple smaller ones. In the same way, a product backlog typically starts with a small number of very high-level stories that are then broken down into smaller ones with gradually increasing level of detail. These are easier for humans to understand, research and find potential solutions for. It’s also easier to validate if and measure how well you have solved a small problem once you think you have the perfect solution.

Properly written user stories document product decisions and the motivation behind them so that any team member, contributor or stakeholder has a shared reference. A product backlog is also a easy to come back to in the future to understand what has been done, and stories help writing release notes and preparing user tests even after they’re done.

Delivering solutions

The high-level recipe for agile product development workflow, from my perspective, is quite simple:

  • User stories are problems.

You can think of a well-functioning agile development team as a machine that runs on caffeine and turns a user story into a new release. The machine did all the changes and additions that it thought was necessary to solve the problem that the user story described.

But Jerry, how do I make sure that my developers don’t do something stupid?

Well, usually developers are smart people with good analytical problem solving skills. By giving them a view to an entire backlog you give them an idea of upcoming features and the direction of the product. They can prepare and avoid conflicts when making design and tech choices for the features they’re delivering right now.

Even when user stories are high-level, vague and in desperate need of splitting, having a shared understanding of the end-user perspective and motivations behind the work that goes into your product helps everyone deliver better results, and helps a development team give input, take responsibility of the product, not just do what they’re told and then get stuck when every single detail wasn’t specified in perfect detail (which never happens).


Stories as input for design

You might be used to designers working in their own floor of your company with their own separate workflow and task management, as an external force acting upon the development teams that work in agile sprints. I think this is a bad practice, mainly because in this arrangement a designer does not take responsibility for end-user output and is not exposed to the realities of software development that will affect the end-user experience. Wireframes, mockups and prototypes are only internal design documentation, not something the end users ever see or even care about.

So what does a designer actually do in an agile team?

Well, on a high-level, every product or UX designer should regard themselves as a problem solver: we’re doing what we do to deliver creative and elegant solutions for the problems that our users face.

What do we need to get the job done? Descriptions and definitions of the problem. Data and data analysis. Information on the users we’re targeting and the impact of our solution should deliver. A good user story includes all these things.

Ideally a designer or a developer — really anyone in the development team regardless of their role — should be able to pick up a story independently. The team should reject user stories that do not contain adequate information on the problem space in a written format.


Checklists

You’ve probably seen this list before, but here we go.

A good user story should…

  • follow the format “As a <type of user>, I want <some goal> so that <some reason and benefit>.”

This format aims to guide and improve the quality of…

  • design decisions

A story can include suggestions or examples of possible solution(s), but should not be fixated on a specific one. I’d advice to resist the temptation to add even that without clear background information on why a particular solution might be desirable. Stick to the problem space!


Summary

I keep coming back to these notes when evaluating and our stories and discussing our product-design-development workflow. I think I’ll come back to the specifics in future posts.

A few things to keep in mind:

  • User stories aren’t in the ten commandments: there are other ways of documenting user needs and other ways or formatting a backlog, like job stories. The general mindset I’ve talked about still applies though.

Quality in user stories will transfer into quality in end-user experience. I’m not the biggest fan of user stories personally, but this is not in contrast to having no set format or criteria for problem definitions and product documentation. I’m sure there’s something better out there, but they’re still a pretty good, tried-and-true way of going about it.

That said, I am working on that something better.


Thanks for the read

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 working with humans.

Jerry Jäppinen

Written by

Users pay your bills–pay attention to them! Love philosophy, games, code and design. Creating industrial-grade products at Lateral Nord. https://lateralnord.com

Lateral Nord

Writings from Lateral Nord on design, technology and working with humans.

More From Medium

Also tagged Product Management

Also tagged User Stories

Also tagged User Stories

The Truth About User Stories

Obi Nwokedi
Feb 6 · 11 min read

1

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade