Put it in the backlog meme

How many items are in your product backlog? 50? 100? 500? A favorite tactic for product managers dealing with stakeholder suggestions is to tell them they ‘will put it in the backlog.’ Unfortunately, many backlog items will languish in the backlog for months or even years before being prioritized for a Sprint. Many years ago I inherited the product management of a B2B SaaS Managed File Transfer solution. The backlog had over 300 items. On average we completed 8 items per Sprint. It would have taken us 3 years to complete all the items in the backlog, assuming no new items were discovered or added. Is Your Backlog Too Big? And are there some new techniques you can use to prioritize it?

In this article we will talk about:

  • The Challenge of Backlog Prioritization
  • Putting Items in the Backlog to Placate Stakeholders is not a Solution
  • Focus on Points of Differentiation, De-Prioritize Points of Irrelevance

The Challenge of Backlog Prioritization

As described in the Scrum Guide, the Product Backlog is an emergent, ordered list of what is needed to improve the product. A good backlog is dynamic – new items are discovered and added, existing items are prioritized, and some items are eventually deleted.

Good product backlogs exhibit similar characteristics. Roman Pichler and Mike Cohn coined the acronym DEEP to summarize several important characteristics of good product backlogs: Detailed appropriately, Emergent, Estimated, and Prioritized. Bill Wake stated that good backlog stories demonstrate INVEST (I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, and  T – Testable.

There are many ways to prioritize a backlog. Ten of the most popular approaches include:

  1. Eisenhower’s prioritizing matrix
  2. Lean Value vs Effort Matrix
  3. Agile Business Value and Risk
  4. Agile Value vs Complexity matrix
  5. MoSCoW Method
  6. Kano Model
  7. Opportunity Scoring
  8. Story Mapping
  9. ICE Prioritization
  10. RICE Prioritization

A challenge many backlogs face is that they contain too many items. In 2010 I inherited product management for a B2B SaaS Managed File Transfer solution The backlog had over 300 items. Google tells us a backlog should have no more than 50 items. Yet many enterprise SaaS products contain hundreds, if not thousands of items. How many items are in your backlogs?

Putting Items in the Backlog to Placate Stakeholders is not a Solution

Product managers and Product Owners rarely want to say No! to a stakeholder. They tell them they will “put it in the backlog for prioritization” and hope that they will leave them alone. Every organization has a method for prioritizing their backlog – some variant or combination of the ten techniques mentioned earlier. These techniques can be supplemented by a technique promulgated by Chris Goward that focuses on points of parity, differentiation, and irrelevance.

Chris presents this simple chart:

Goward Venn Diagram

Goward, Create an Awesome Value Proposition with These 3 Points

  • Points of Parity (POPs): These are the features you offer that are important to your prospects that you also share with your competitors. Most marketers spend their time here, loudly trumpeting how they can do what their competitors do too, only *better*! That’s a strategy to fail.
  • Points of Difference (PODs): Here’s where you can win the game. These are the features that are important to your prospects and not available from your competitors.
  • Points of Irrelevance (POIs): You may have spent a lot of effort developing great features, but if nobody wants them, you should kill them.

Most backlogs contain a high number of items that are points of irrelevance.

Agile parking lot

New York Times

Focus on Points of Differentiation, De-Prioritize Points of Irrelevance

You should add Chris’ criteria to your backlog prioritization scheme. Build a ‘parking lot’ backlog and move all items that are points of irrelevance into it. Structure your backlog so it contains enough items to cover sprints for the next six months. Anything that falls outside of the six-month time frame, moves to the parking lot.

Lutz Mueller wrote a great article entitled How Many Items Should a Product Backlog Have? He lays out a good process for determining how many items your backlog should contain based on your sprint velocity. He provides examples of how to calculate for a four-month cycle, a SAFe Program Increment, and an OKR Cycle. He summarizes his approach as follows:

Use the following steps to identify the maximum number of items in your Product Backlog:

  1. Set your time frame
  2. Identify the number of sprints during this time frame
  3. Identify the average number of completed items per sprint
  4. Calculate: Maximum number of items in Product Backlog = Number of sprints in the time frame * Average number of completed items per sprint
  5. Optional: Round the number to a memorable number.

How Many Items Should a Product Backlog Have?

Summary

Backlog management is a core responsibility of product managers and product owners. Over time backlogs can grow to an unmanageable size. There are many techniques to prioritize and rationalize backlogs. You should consider adding some new criteria, Points of Parity, and Points of Differentiation. Points of Irrelevance should be deleted. 


Also published on Medium.

By John Mecke

John is a 25 year veteran of the enterprise technology market. He has led six global product management organizations for three public companies and three private equity-backed firms. He played a key role in delivering a $115 million dividend for his private equity backers – a 2.8x return in less than three years. He has led five acquisitions for a total consideration of over $175 million. He has led eight divestitures for a total consideration of $24.5 million in cash. John regularly blogs about product management and mergers/acquisitions.