Summer Project - Build a Bigger Product Backlog

While working with some of worlds best product development teams here at Appfire, we often come across the same myth. The myth that "it's the job of the Product Owner (PO) to maintain and grow your product backlog".

When we coach agile teams, the first things we want to see are: (a) how many Sprints have been planned ahead of the current (active) Sprint, and (b) how many unplanned stories are in the backlog. Combined, those two metrics usually provide a good indication of whether a company subscribes to the myth.

Small Backlogs Make it Difficult to Plan Ahead

Product teams that have a small backlog often have a hard time planning ahead of their current Sprint. We like to see our customers planning between three-and-five Sprints ahead of the current (active) Sprint. Your next two Sprints will ideally be planned in detail, with further Sprints remaining at a high-level.

When we hear customers say things like: "...we haven't finalized the plan for our next Sprint", or "...we didn't want to publish our next Sprint plan because it might set improper expectations", it's likely because their backlog is far too small. The real reason they don't have future Sprints planned out is because the exercise of planning is frustratingly difficult when you don't have a clear idea of what your product team is going to be working on.

Harboring the Myth can be Dangerous

This problem often goes unresolved within teams. I've seen cases where it's lasted for years (many generations of a product). As humans, we find ways to busy ourselves for the next Sprint. At the last minute we'll devise a plan to execute against. There's no doubt that the plan will include some items that we feel are important to the future of the product. Maybe some "technical debt" that's been building? Maybe we spend a Sprint cycle prototyping something that the team has been looking to introduce? That's how we justify it away from being a non-productive Sprint.

Harboring this myth for an extended period of time has a significant and long-lasting negative impact on your product. The longer you harbor this myth:

• The more likely it is that you will delay the release of your product.
• The more expensive it will be to produce your product.
• The less innovative you will become.
• The more likely it is that you'll allow your competitors to win more customers.
• The less informed your product team (especially Sales and Marketing) will be on the future roadmap of your product.
• The less informed your customers will be of your future plans for functionality which impacts their use.
• The greater the chances that your product will not make it another generation.

Your Summer Project - Help Build a Bigger Product Backlog

With this myth in mind, we've prepared a summer project for you. Ask the following questions about your product, and encourage all of the members of your team to participate - including engineers, support, marketing and sales:

• Think about the features or functionality that do not exist in your product today, but should.
• Look closely at your competitors. Review their features and compare them to yours. Analyze what they're saying about the direction of their product and determine if that direction also makes sense for yours?
• Review what analysts and experts are saying about your products and your industry.
• Ask your customers what they would like to see in your product. Your customers are often your best idea generators. You know who they are, where they are, and usually all you need to do is ask!
• If you have partners who OEM, distribute or integrate your product with theirs, ask them for their feature input.

The bottom line is that your PO is not solely responsible for building your product backlog. It's the job of the entire product team. If it looks like your team is harboring this myth, then it's time to take on our summer project and help grow your backlog!

Building a bigger product backlog allows your team to plan ahead of your active Sprint. Looking ahead allows you to make important adjustments to your product, marketing and sales plans, which in turn helps to protect the interest of your product and everyone involved.

Is your team effectively planning, or just harboring a myth?