The Product Backlog Hinders Value Creation – Part 1

(I did a lightning talk with this title at XP2010 in Trondheim, Norway, and thought I’d do a write-up of it as well. This is part 1.)

Ok, we all want to create value with your software projects. Using agile methodologies is a great way of accomplishing that. But as I’ve gained experience with agile methodologies, I’ve surprisingly found that the Product Backlog is actually hindering us from developing the most valuable software. It’s hugely superior to the standard requirements documents of the Dark Ages, but still – when it comes to creating maximum customer value, the Product Backlog is a hindrance.

I think there are three problems with it.

Huge pile of means

Problem # 1 is that the Product Backlog is a long list of means. It doesn’t state customer goals or customer value, but means. That is, it doesn’t say where the customer wants to be, only how the customer intends to get there. In very small steps, called user stories.

Let’s take a look at a typical user story:

As a repeat user
I can personalise my start page
So that I can get quick access to stuff I care about

That last line hints at a need for a type of user. However, it says nothing at all about why the customer would want to spend money, time and energy on developing, testing and deploying this functionality. Fortunately, good agilists habitually use this important question:


So, when discussing a user story with the team and the customer, we ask “why” – often multiple times – to work our way backward from the user story itself to the reason for it – the customers’s goal with it, why the customer values it. In this case it might be that the customer has a problem with users not returning, and it would be valuable to the customer to get the users to come back (and possibly spend more money there) – and this user story is one of several means to accomplish that.

Now, when the goal is found, we then ask “Now, is there a better way to reach this goal?”, possibly resulting in a different set of user stories.

But this is quite a backwards way of discovering the customer’s goals. If we want to create maximum value, there must be a better, more direct way.

Huge pile of means

Problem #2 with the Product Backlog is that not only is it a pile of means; it’s a huge pile of means. Imagine a Product Backlog with 500, 200 or even just 100 user stories. It’s quite difficult to look at a Product Backlog that size and figure out where the value is. Also, it gets increasingly difficult to apply the “why” question as the Product Backlog increases in size.
Sample Product Backlog

Focuses on functionality

The third problem with the Product Backlog is that it focuses on functionality. A Product Backlog consists of user stories, and the user stories describe what somebody can do with the system, the system’s functionality. But

It’s not about the functionality!

Let me repeat that, just to make sure it’s not misunderstood:

It’s not about the functionality!

Think Twitter, or Google Docs. They didn’t succeed because of loads of functionality. Or let’s use a replacement project as an example. The reason for the replacement project is not that the customer wants more or better functionality. (Even though we sometimes add that as a goal, probably to make it more likely the project will fail.) The reason is usually something like

“This system is running on crap software and crap hardware. We need something better, or else…”

And if we analyze that, we find that the reason for the project is that

Something needs to be improved for somebody.

I believe that’s true not only for replacement projects, but for all projects, including those we software people are often involved in – product development or product improvement. And then we better start by figuring out who these somebodies are, and what this something is, and what improved means.

We’ll explore the value process further in Part 2.

This entry was posted in Agile, Scrum, value and tagged , , . Bookmark the permalink.

9 Responses to The Product Backlog Hinders Value Creation – Part 1

  1. Pingback: Tweets that mention The Product Backlog Hinders Value Creation – Part 1 « Leaning Agile --

  2. Harald says:

    Great article. Patiently waiting for part 2 (of 2?).

  3. trond says:

    Thanks, Harald! Part 2 – of 3 🙂 coming today.

  4. Pingback: The Product Backlog Hinders Value Creation – Part 3 « Leaning Agile

  5. Andrej says:

    Don’t trust your Product Owner very much, do you?

    Why do you want to redo all the work the product owner did to create the Product Backlog? Why do you think the team should redo this work and again decide if all the user stories are relevant?

  6. trond says:

    Andrej, thank you for commenting!
    It’s not that I don’t trust the Product Owner. It’s the focus on means as the foundation for steering the project that I think is flawed. I think clarifying the stakeholders, their values, and what this means in terms of product goals, is a much better starting point if you want to create customer value. Basically, giving the Product Owner a better tool for steering the project than the Product Backlog is. Make value explicit!

  7. “Something needs to be improved for somebody” is the crux of the matter, but too simple in todays world of marketing jargon and doublespeak

  8. Thomas says:

    I always like when people try and turn holy stones to see if a process is flawed so it can be improved.

    But if you have 100 userstories that need to rewritten it is the makers of the backlog that failed making it.
    When making userstories the product goal and focus areas for the product and the next sprint should be defined.
    Then write userstories with the stakeholder asking him why and get the userstories right.
    The back log should only be accurate and precise in the first part of the backlog. Then fading to more and loose stories.
    Keep it up 😉

  9. Louie says:

    I see you don’t monetize your website,i read awesome article how to earn some extra
    money and increase traffic using one simple method, just search in google for – How to monetize a blog Twardziel advices

Leave a Reply

Your email address will not be published. Required fields are marked *