Product Backlog Flows

By Robert Boyd
August 13, 2015

There are plenty of discussions in the agile community about how agile teams work and develop over…


There are plenty of discussions in the agile community about how agile teams work and develop over time. Often neglected or poorly understood is how that work makes its way from the customer to the team. Below is a blueprint for creating an effective and efficient flow of work. I’ve included details but also left it flexible enough to be customized for your company’s specific circumstances.

The Problem of Transparency

The blueprint for the product backlog flow focuses primarily on increasing the visibility of how customer requests make their way to the development team. Agile and lean startup emphasize the importance of customer involvement from ideation to product release and beyond. By making the customer request process more transparent, all stakeholders—including customers, development, product management, product marketing, marketing, sales and support—can provide input and feedback. For the business, it places a real focus on customer requests and personalizes customers for internal stakeholders. The customer request ceases to be a number and becomes a problem that the customer needs to solve. The entire business will then tackle the customer’s problem as if they’re helping a friend.

The requestor, or more likely, the customer proxy or business sponsor, also benefits from this transparency; now they can see how their request is progressing. The customer proxy can keep the requestor up to date on where their request sits.

Product Backlog Flow Overview

The product backlog flow consists of four sub-flows that occur simultaneously, but independently. These flows deliver customer pains and problems to the agile team. You can visualize them using a variation of Mike Cohn’s Product Backlog Iceberg, shown at right.

These four flows work most efficiently with up-to-date accurate prioritization and lean’s just-in-time techniques. Stories will move from feature requests to future releases, then to release, and finally, to sprint. Of course, features have a finite validity runway, the timeframe where product/market fit remains intact and the product owner and business believe that the feature’s core capability will not change. Moving epics up the product backlog too soon introduces the risk of wasted work if a feature is dropped for any reason.

From Ideation to Release: The Nilezon Example

Let’s start with a marketplace app called Nilezon, created at an imaginary company by the same name. As a customer, not only do you want the Nilezon app to remind you that your mom’s birthday is coming up in a week, you’d like Nilezon to automatically send mom a birthday present based on some criteria you previously entered. Mom gets her gift from you, your forgetfulness is covered up and Nilezon gets paid from your credit card. It’s a win-win-win situation.

You send your product enhancement idea to Nilezon and wait for the new app release that includes your feature. Nilezon sends a thank-you note and asks you to monitor Nilezon’s Twitter and Facebook pages for product development news. Then Nilezon begins the process of transforming your idea into a working product.

Feature Request State

Product management or marketing documents the new feature request somewhere that’s accessible to all internal stakeholders. It could be in a CRM tool, Confluence, a spreadsheet or even on a wall.

The idea goes through a review process based on some set of established rules to see if it warrants further research. At Nilezon, it is based on the number of similar requests and on the current and likely feature sets of competitors. Lucky for you, this is not the first request for such a feature. The next step then is for product management and marketing to conduct a business feasibility study on this latest feature request, now nicknamed Mom’s Gift. They must establish a business model canvas to identify the problem, a possible solution, unique value proposition and customer personas. Then they begin validating the customer problem to verify that it’s worth solving.

At this point, it may make sense to add new feature requests to a Kanban-like board to increase visibility and help product management and marketing manage their portfolios (Figure 1). Throughout the process of establishing a business case, ongoing visibility allows stakeholders to make suggestions about the solution, how to market and how to sell the new product feature, all of which are captured on the business model canvas.

The timing for moving ideas into future release will vary by company. For example, within Nilezon, there’s a small start-up component that takes new ideas through to problem/solution fit and lays the groundwork for establishing product/market fit. Once product management and marketing are satisfied that there’s a valid business case—and the feature has a high enough business priority—Mom’s Gift will be submitted to the executive committee for approval.

Once the executive committee approves the feature, Mom’s Gift will move onto the product backlog as a roadmap item. Without a definite release date, it will go into the future release state.

Future Release State

Future release items in the product backlog represent a collection of features encapsulating real customer problems that the business believes are worth solving.

Items in the future release state have a more complete business model canvas where problems are validated with customers, and cost and revenue are roughly estimated. Each item is prioritized and includes a description, customer acceptance criteria and an estimate.

At Nilezon, the Mom’s Gift feature has been formally added to the product backlog. A lot of unknowns remain, including a high-level architecture and validation for how the customer would set up criteria for automatic gift selection. The product owner and a technical subject-matter expert (SME) will do a rough feasibility study to identify any high-level risks.

The strategic and tactical business concerns are the prime focus while a feature epic rests in the future release state. The number of product backlog items in future release will generally match the company’s product roadmap length. If the roadmap projects the next 24 months, then you would have 24 months worth of estimated product backlog items in future release and release.

Page 1 / 2

About the Authors

  • Robert Boyd is a CSM (Certified Scrum Master) and CSPO (Certified Scrum Product Owner). Robert began his career with the U.S. Navy, where he worked on nuclear submarines. He transferred his skills to the private sector, working on submarine combat systems at Raytheon for 22 years. During that time he helped streamline processes and systems for the Australian Collins Submarine. He moved to Australia permanently in 2002 and began creating new software development processes for Integrated Research in Sydney. He also introduced agile methodologies to software and product management departments, resulting in a 300 percent increase of feature deliveries. Bob earned a B.S. in computer science from University of Rhode Island. He can be reached at

Post a Comment


Allowed HTML: <b>, <i>, <u>