Is the Product Backlog an Idealog?

What is a product backlog?  I think most people who are working to the agile ethos will agree with the Scrum Alliance’s Guide description as “… the master list of all functionality desired in the product.” This definition is open to interpretation.

It’s that bit about “all functionality desired” that gets me.  Does this include everything that your product owner says they want?

Approach A – All ideas live in the backlog

The most common viewpoint I’ve come across is that the product backlog is everything the product owner has expressed an interest in.  I don’t know about you, but not everything this type of backlog is estimated in points.  You know the deal, the backlog gets big quickly with an enthusiastic product owner waxing lyrically about their dreams for the system, making the cost of fleshing out all stories pretty expensive.  There is nothing wrong with the product owner doing this, after all they are telling you want the want which should be a good thing.  To deal this the barrage of information we end up with epics and themes.  Both of these concepts will be decomposed into many user stories as we discover more about their purpose, but in the mean time they are placeholders of functionality to be built “later”.  The other side affect of a long backlog, epics and themes is that your backlog is strictly prioritized at the top and loosely prioritized at the bottom.  The advantages of this style is that you have all of your ideas in one place – a complete view of what the product owner has requested.

Approach B – The backlog represents commitment

The alternative is that your backlog only contains user stories that your product owner has committed to.  Commitment means that the product owner is prepared to pay for these stories.  Paying means spending the time and effort to think through each of the stories in detail and go through the estimation process.  It also means prioritizing all of the user stories.  “Nice to haves” and “maybe one-days” don’t end up there.  Instead another bucket is needed to hold future thoughts, I call this and Idealog.  In there you put features, epics and stories that wont make it in because of resource constraints (time and money) that you want to get to but you are not not ready for yet.

I think these two views of the product backlog have evolved for projects with different drivers.

When you are project oriented

Well defined projects have a specific goal they are trying to achieve, usually withing a fixed time or price.  The projects I’ve worked on end up with all of your ideas in the backlog, i.e. approach A.  If your product owner is very enthusiastic and generates lots of features it will become quickly apparent what will roughly fit within your constraints.  This means you can have a long list of everything your product owner desires and you can draw a line through the product backlog where you run out of resources.  It doesn’t matter if items at the bottom of your product backlog are a bit fuzzy.  This is how the “Big Businesses” I’ve worked for (like banks) work.  i.e. a business case is created, you get funding to create the business case, and you satisfy the goals within your budget and wind down the project.

When you are product oriented

Sometimes though you work on a product which does not have an end.  It, like your project, has a goal but the goal is usually nebulous or grander in vision.

Many start-ups I’ve worked at have a business model that is continually evolving.  Not only do they not know what they need in two months, they want to continue development for years (if all goes well of course).  In this case your backlog looks very different.  If you add every feature your product owner has contemplated, then your product backlog can become enormous.  One company I worked in had accumulated 2,000 stories after two years (including features and bugs) – the result was to delete the entire backlog and start again.  The logic was that if it was important then it wouldn’t take long to resurface (yeah, it was out of control and shouldn’t have got to that state).  Seriously, who can manage a backlog with so many ideas in it?  This is where an Idealog comes in.

An idealog should contain high level ideas to be debated, analyzed and decided whether they show enough merit for the product owner to commit to.  Until then, let them swim around in the primodial soup until they grow legs and walk into the backlog.  The backlog contains the details which are ready to go and the Idealog contains longer term plans which may or may not be done.

Who cares about a definition anyway?

The Agile Manifesto says nothing about a product backlog.  XP talks about a release plan but nothing more.  As I’ve mentioned earlier, Scrum talks about a product backlog pretty loosely.  But really, what does it matter?  If you can deliver what your product owner needs in a way that makes them happy then your doing something right.  Choose the right approach for your needs.

Personal experience

I’ve used a product backlog in both ways and they both have merit.  I prefer using an Idealog, I think it keeps the backlog clearer but I’ve used both methods effectively.

What do you do?  What do you think?

  1. I use Idealog as well. We’ve tried to put most ideas into Backlog and it quickly become a mess. In TargetProcess we have Requests (ideas and issues), so now we collect all ideas in requests list (currently it has about 600 active ideas, I mean not rejected). Each idea has Votes attached (for example, top idea has about 40 votes). Based on votes and own vision I create stories from ideas that we are going to implement in the near future (let’s say about 2 month horizon) and that forms our Backlog. Works very good, since it is quite easy to prioritize the backlog.

    Idealog is a good name :) Maybe we will use it in future releases of TargetProcess, if you don’t mind ;)

  2. Dan Prager says:

    I also think that method B wins. With the long list approach you inevitably get duplicates as ideas that were at a low priority get re-added rather than promoted, adding further to the management burden. It just doesn’t seem agile.

    That said, in the more public sphere, UserVoice combines method A with search and votes to good effect.

  3. A really good thought provoking blog. Well done!

    I personally am in favour of a single backlog. I think if managed well, (I know, it’s not easy but with the right tools ….) it’s a far better option. I hate having to manage multiple lists. It quickly gets out of hand. Additionally, you never know when or where that next great idea is going to come from. And if ideas arn’t taken seriously they stop coming up with them. There’s really something impactful about telling a customer “it’s on the backlog”

    Also, one other comment, stories don’t and should not only come from the product owner/s.


  4. Rich Mironov says:

    I use both approached, but for different purposes. As you suggest, project-specific teams really want to work down the backlog of things that are truly needed for that project. Putting things on such a backlog that won’t get done (or are for other projects) simply creates a sorting/filing problem later.
    As an agile product manager (often a/k/a product owner), I know that my product will live on for a long time. Years and years if it’s well-received! I want a place where good ideas can live for a while, even outside the scope of what the team can build in this sprint or this release. Many agilists would refer to this as the product backlog, rather than the release backlog or sprint backlog. It includes variously underdefined things that may get more definition later.
    Great to call this an IdeaLog as long as it doesn’t generate yet another disconnected list of things that need to be found and re-integrated later.

    See some of my thoughts on agile PM at

Leave a Reply