Lessons from a 10-Year Long Product Backlog
Product Backlog Management Tools: When & Why?
I am often asked, “What tool should we use for Scrum?” or “What tool would you recommend for managing a large Product Backlog?”
Recently the Product Backlog question came up regarding a tool called CaseComplete, so I’d like to share my experience with managing Product Backlogs in complex product development.
The 10-Year Product Backlog Story
In 2009, I was coaching an Agile transition with a large European software client who had 400 developers across 5 locations. We were using Excel to manage the Product Backlog (PBL) with 12+ Product Owners and it was very painful. The Product Backlog had 1200 items in it and represented 4 years of future work by the whole development organization.
Product Owners would edit their own copies and then have to merge their changes manually in multi-day meetings. We started looking at Requirements Management tools like DOORs, RequisitePro, Rally, and others. Since the company had a license for IBM RequisitePro, we attempted to use it. However, RequisitePro was very difficult and inflexible. In many ways, it was worse than Excel. So, after some real world user testing, we abandoned it.
The Product Owners continued to add Product Backlog items and last I heard, in 2012, the PBL contained over 3000 items and was virtually impossible to manage. It also represented a massive 10 year inventory of work.
How Agile is a 10-year Product Backlog? Of course, it’s not Agile at all. On average, any new item entering this queue will take 10 years to complete.
Saying “No” Decreases Inventory and Increases Agility
If your Product Backlog is so big and complex that you think you need a tool (beyond cards or Excel) then most likely the problem is your Product Backlog itself.
If the Product Backlog is too big and too complex then the solution in not a tool, the solution is to simplify your Product Backlog.
Agile Manifesto’s first value is individuals and interactions over processes and tools, and this is the key value to make product development successful.
If there are hundreds of software developers building one product, maybe a tool will be valuable. However, my experience is that these tools actually reduce the amount of collaboration and shared understanding between the people defining what is needed and the teams doing the work.
The Three-Month Product Backlog
When I am coaching product management staff (POs, BAs, Directors, etc.) these days, my advice is to keep your Product Backlog to at most three months of work. Yes, only three months (queue catcalls and shouts of “that’s impossible here!!”).
Beyond three months, I coach POs to tell stakeholders that they will come back and consider new items next sprint, but for now they cannot put it into the Product Backlog unless they are going to remove something else.
This shortens conversations with stakeholders greatly, and makes the Product Backlog much easier to manage since it is only three months long. It also has the nice effect of keeping stakeholders engaged when they need to be. If stakeholders can’t get their item in the next three months they may look for alternatives, and that is a good thing.
Saying “no” to stakeholders increases their agility since they can consider alternatives (for example, they may buy a solution) instead of waiting years and becoming very frustrated as they did in the company with the 10-year Product Backlog.
A three-month Product Backlog works very well because it provides product Agility and gets rid of the need for useless complicated tools for huge and hard to manage Product Backlogs.
I am not saying tools cannot provide some value. They can. However, tools often enable bad behaviours that reduce communication and Agility.
Remember, individuals and interactions over processes and tools.