Why SCRUM Backlogs lead to bad Product Decisions

Thomas Schranz
Jan 29, 2014 · 5 min read

I used to be a huge fan of SCRUM sprints and backlogs when it comes to planning software projects but the more I dive into product management the more I view them as anti-patterns that lead to bad product decisions.

What’s a Backlog?

In theory a product backlog is a list of requirements that you’ve committed to implement. As simple as that.

For most software teams the product backlog is the manifestation of what gets built next. This works well as long as you manage to keep the backlog well groomed and manage to keep everything out that doesn’t belong there.

The Backlog easily turns into an “Everything Bucket”

In reality though it is really difficult to protect the product backlog in that spirit. I’d even argue it is impossible. It’s way too tempting to put everything into the backlog that sounds like a great idea which you don’t want to forget about.

Other times adding a feature request to the product backlog is the only way to keep pushy stakeholders happy without actually having to add the feature to the product immediately.

Image for post
Image for post

Most backlogs I’ve seen feel more like “everything buckets” or pools of ideas & inspirations than actual requirements that are essential to the product’s success.

The following two tweets by Stephan Schmidt really capture the essence of how I feel about backlogs.


I think in a time where we can ship new versions of our software almost immediately it is time to really embrace just-in-time concepts.

Committing to granular work items way before you even get to implement them doesn’t make much sense anymore.

If you still use a backlog I’d only fill it with epics or high-level themes.
But I think there’s an even better way than that.

Replacing the Backlog with a Product Strategy Roadmap

At Blossom we’ve completely replaced our product backlog with a free form Google Docs file. It reads more like a marketing document than a traditional backlog. We call it our product strategy roadmap. In this file we’ve defined a few simple things on top …

Then the body of the document consists of high level (strategic) marketing-esque announcements of (future) product improvements. Similar to what you would read in a blog post when a company like Facebook, Apple or Twitter releases a new major feature.

Image for post
Image for post
An Example Announcement from Twitter (Friendlier photo sharing)

The interesting thing here is that these announcements focus on the benefits and the intention of where we want to take the product and what’s in it for our customers.

It’s not a descriptions of features. It’s a higher level announcement text that helps to put features and other product changes into context.

Image for post
Image for post
An Example Announcement by Facebook (Introducing New Apps for Timeline)

I really prefer this format to a traditional backlog as it focuses on the customer benefits and is therefore easy to share with all stakeholders.

It also reminds us about what to focus on with product decisions. It is less about having a lot of ideas and more about telling a story and being great at editing what gets in and what is consciously left out.

Pulling from the Roadmap

Then every time space on our product board frees up we take a look at our roadmap document and pick something from it to pull into our process.

This might be a full ‘announcement’ at once or more often just a subset of an announcement that we then work on step by step.

Image for post
Roadmaps in Blossom

The main advantage here is that we have a strategic document that’s clear and concise but at the same time very easy to change. It is very high level and mainly there to provide context for what a great execution of the strategy might be.

We don’t start with specifying implementation details until we’ve actually started to work on an item. This saves a lot of time and resources that we used to spend on doing backlog estimates, re-prioritizations and groomings in the past.

What’s your take on product backlogs? How do you handle them?

If you found this post helpful follow me on twitter where I tweet about Software Development & Product Management ☺

Image for post
Image for post

Also make sure to check out Blossom an Agile/Lean Project Management Tool I’m currently working on ☺

Product Love ❤

Posts on Product Strategy, Management, Design, Development…

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

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