What is a Product Backlog in Agile?

For Agile projects to be successful, a carefully constructed and correctly prioritized product backlog is critical. If the backlog is incomplete or inaccurate, an Agile team may expend time and energy creating features or products that don’t satisfy customers’ real needs. The requirements listed in the backlog must accurately describe what customers want and deliver the value that they are requesting.

Requirements in a product backlog may be incorrect or misleading due to several common causes:

The product owner may be overworked

If the product owner is working on too many projects or has too many responsibilities to fulfill, he or she may not collect or prioritize items in the backlog appropriately. You may need to reapportion work to ensure that it is completed accurately and is ready for selection by the team during iteration planning. For example, several individuals may need to take responsibility for items in the backlog (rather than having one product owner maintain all of the items in the backlog) to ensure that they are ready for planning.

The product owner may lack necessary knowledge or skills.

The product owner must have a working knowledge of the product so he or she can speak constructively with stakeholders and team members. The product owner must also have a deep understanding of the customer and the market, to ensure that the requirements are truly of value. If your product owner lacks the skills or knowledge to manage the product backlog correctly, you may need to provide training or reassign the owner to other tasks.

The organization’s mechanisms for collecting requirements may be inadequate

Product owners must have access to the right customers—ones who are knowledgeable enough about the product to provide useful feedback and to describe requested features in enough detail to be helpful to the project team. Make sure that your organization has a clearly defined view of its customers and that it shares information about customers across teams and departments. Establish strong relationships with customers and develop simple ways to collect and verify their feedback (for example, with customer surveys and interviews, focus groups, iteration reviews, and direct observation of their work).

The requirement descriptions may be vague or too prescriptive

Customer needs should be descriptive enough to be understood and helpful to team members in planning for iterations, but must not be so overly specific that they constrain the team’s options to fulfill the requirements. Writing accurate requirements can be difficult for new product owners and they may need to undergo training to be able to do it accurately. Teams may also need to push back on product owners if the requirements are not described with enough accuracy. Some teams have even included a ready definition (much like the definition of done) for its requirements; requirements must be configured correctly and be “ready” for use in iteration planning. If a requirement is not written in a way that is complete and helpful to the team, it is sent back to the product backlog for additional information and reprioritization in later cycles.

The requirements may be incorrectly prioritized

If the product owner is focused on optimizing the production process instead of satisfying the customer, he or she may place more emphasis and higher priority on items that don’t provide the greatest amount of customer value. Agile products are designed to give the customer the greatest value possible; to do so, you need to make sure your product owners (and other customer proxies) reflect the needs of actual customers and that they are intently focused on current market conditions and demands.

Prioritizing the Backlog

There are many ways for Agile teams to prioritize the items in a product backlog. In the article “Prioritizing the Product Backlog” on AgileSoftwareDevelopment.com, Peter Stevens suggests six possibilities to consider as you prioritize your list:

1. Prioritize so you complete a set of minimally marketable features (MMFs) first. Narrow the large backlog down to a smaller set of options that the team can choose from to plan iterations. Include “exciting” features that will delight customers and motivate them to purchase the product.
2. Prioritize to deliver the requirements that provide the highest business value first. Consider requirements that provide value to the customer and to the business. For example, include requirements that reduce business costs, eliminate waste, or improve efficiency.
3. Prioritize so you provide the most value for the least amount of effort and cost. Choose requirements that are easy to implement but are still exciting to customers.
4. Prioritize so that you address the highest technical risks first. Consider tackling those items that would be hardest to implement, to get them out of the way. (Be careful; you may expend resources developing solutions that are never implemented or would be better addressed at a later date, when more is known about an issue.)
5. Prioritize so that you defer risks to later in the cycle. Selecting lower-risk items first will allow rapid progress and may provide insight into ways to tackle higher-risk items in a later iteration.
6. Prioritize by letting customers and users vote from a list of possibilities. The Rally Software Development Corp has successfully used this option on their web site to let users suggest new features, allowing all users to vote to determine which features will be included in subsequent releases. Selecting the options that customers have voted for ensures that products satisfy customer needs.

The method you choose should be the most appropriate one for your product, organization, and situation.

If you still have trouble and need additional training, consider visiting the Conteneo web site and clicking into the Instant Play Games for creative and fun ways to train your team. For example, you could use the “Bang-for-the-Buck” game to help your product owner and product team place product backlog items on a chart, based on their perceived value and cost. Playing the game clarifies issues and ideas, and encourages discussion about an item’s short-term potentiality and long-term value. Other games from the site provide insight and assistance in understanding customer and market needs and help Agilists prioritize their work to ensure the greatest value in their projects.

Mini case: Customer Conflict

Daichi Ikeda turned on his computer to check his email, just as he did first thing every morning. Ikeda was the Reagents Supervisor for Fenikkusu Compounds, a chemical production company in Fukui, Japan. The first message he saw was from Senzai Textiles, one of Fenikkusu’s biggest clients. Fenikkusu had been developing a new surfactant to keep dirt from adhering to Senzai’s products.

Eiko Oshiro was the product owner for the H240 project when it was finally transitioned to Senzai. She had been with Fenikkusu for several years but had never worked in the surfactants division nor had she worked on projects for this client. She had been assigned at the last moment when the original product owner had become seriously ill and had to leave the project.

Ikeda called Oshiro to his office to discuss the problem.

“As you know, this is a new product that Senzai asked us to develop,” Oshiro said. “They never raised the compatibility of the surfactant with their waterproofing materials as a requirement. I didn’t imagine that it would present a problem, but then again, I don’t have a lot of experience with surfactants.”

“We did our best to keep Senzai involved and we solicited their feedback on numerous occasions, but they never really engaged in the process. We asked them several times to join our iteration reviews and they agreed, but then didn’t show up. I have some industry contacts who have created similar products in the past, so I asked them to act as ‘stand-ins’ during our iteration reviews. The stand-ins were very helpful and really liked the final product but we never actually had a chance to work with the Senzai representatives or test it with their products. They were very secretive about their new waterproofing materials and didn’t want to expose us to their proprietary information.”

“We’ve always had a problem keeping the Senzai representatives involved.” Ikeda said. “Did you review the other projects we did for Senzai?”

“I looked for documentation, but there wasn’t a lot available,” she replied.”I wanted to speak to the product owner from the last project we did with Senzai, but he was let go during downsizing last year.”

Question

Answer the question in the textbox, then click Submit to compare your answer to an answer written by an experienced project manager.

How could this situation have been avoided?

Suggested/Sample Response

Oshiro’s lack of familiarity with the customer and the surfactants product line made her a poor choice to serve as the product manager for one of Fenikkusu’s biggest clients. The product manager should have extensive knowledge of the customer and the product; Oshiro’s lack of knowledge has compromised the product and, by extension, the company’s relationship with its client. Oshiro should have received more guidance and training before she was chosen for the project.

Fenikkusu has provided products for Senzai in the past, but information about this customer’s behavior had not been shared within the company. If project team members had a clearer view of the customer at the beginning of the project, they may have known that customer involvement was a problem and taken measures to account for it.

The incompatibility issue suggests that the customer requirements were not specific enough. Perhaps with a clearer understanding of the intended purpose for the surfactant, the team may have been able to test the chemicals with similar products to ensure that there would not be any problems.

Oshiro also chose the wrong proxy to represent the customer. Although this proxy may have helped the team complete its iterations, ultimately the team created a product that did not meet customer needs.

Recommended for you Agile Transitions for Managers