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?