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.
During this stage, the product owner keeps an open and running dialog with customers and potential customers. This is part of the ongoing review to confirm or adjust the priority of the product backlog based on business value. This priority can change at any time. Perhaps the feature in the product backlog loses its competitive advantage or there’s a spike in requests for it.
At Nilezon, the product team manages stakeholder expectations by keeping them informed of any changes in business value or priority. The product owner keeps the product backlog and business model canvases available and accessible to all stakeholders.
A product backlog item moves to the release state when it’s the highest-priority item in the future release column and a spot in the release column opens up. The item is now tagged for a specific planned release. The product team makes every effort to complete the business model canvas for Mom’s Gift. All customer problems and solutions are validated. The product owner and technical SME conduct a detailed analysis including a high-level architecture and more comprehensive risk analysis based on the design. User interface mockups are created and validated with customers and users.
Features are reviewed and analyzed by the agile team that is expected to implement the epic. The feature epic may be broken down to facilitate estimation or to isolate its riskier aspects. The goal is to confirm the feasibility of implementing the feature within a specific release window.
The product owner is responsible for maintaining the priority of product backlog items in the release state. Once a week, the product owner of Mom’s Gift reevaluates the business value and priority of product backlog items with the other product owners.
A product backlog item will move to the sprint state when it’s the highest-priority item in the release column and a spot opens up in the sprint column. The backlog item is broken down into smaller, more manageable pieces of work that can be completed inside a single iteration or sprint. Because development will have addressed outstanding questions in earlier meetings, that team will already have a thorough understanding of these small slices of functionality—known as sprint-ready user stories.
It takes Nilezon’s development team four sprints to implement Mom’s Gift. Each sprint adds functionality and capability, and the results of each are shared with stakeholders and customers so they may determine whether the development team and product owner are building the right solution.
When the acceptance criteria are met for all user stories and customers and stakeholders agree the feature is fit for its purpose, the product backlog item moves into the “Done” state, completing the journey through the product backlog.
Incorporating the four sub-flows into your product backlog flow will increase the transparency of the customer request process and ensure that each stakeholder can provide input and feedback. It places a real focus on customer requests and personalizes those customers for internal stakeholders.