Working With The Product Backlog

Outcomes vs Outputs

It can be very tempting to only think about delivering items from the Product Backlog and produce numerous outputs from the Sprints. However, this approach is a tactical one that only really thinks about the near term rather than thinking longer term. The ability to think strategically to consider higher level outcomes rather than low level outputs can provide more alignment and a proactive intention behind the work and the Sprints.

Understanding the outcomes may only be achieved through some good customer research and understanding of the customers’ needs and taking the time to gain deeper insights.

Defining Value

Focussing on a value to market strategy requires an understanding about what value is and what it means to the end users and customers. Value could, for example, be related to the following:

• Revenue – the potential income earned from a particular product or feature
• Efficiency – the cost savings from automating a part of a process for example
• Compliance and Fine Avoidance – the cost saved from satisfying regulatory compliance objectives
• Customer Attraction – the exciter feature that attracts more customers to use the product
• Customer Retention – the desired feature from feedback of existing customers
• Return on Investment – the return on doing a piece of work far outweighs the costs of doing it
• Maximize Learning – validating a key question or assumption that may influence the rest of the work
• Minimise Risk – the ability to neutralise a key risk in the work

Qualitative vs Quantitative Valuation

How to define what is of higher value can be from an objective evaluation criterion, which might involve numerical scoring and analysis to arrive at which features score highest, or it can be subjective with an intuitive understanding of what features are more valuable than others.

The objective quantitative scoring of features can be a quick and easy approach when working with a large number of items, however, it may also be limited to the criteria used and whether it truly aligns to the customers’ needs and wants. This approach can also promote “gaming the numbers” behaviour when working with multiple competing stakeholders, who try to influence their desired features above others.

The subjective and qualitative approach to select high value items is a quick approach to select a few items and is good when there is a deep knowledge of the problem space, however, this may be based upon personal experience and influenced by cognitive bias and mental models. Hence, it may be difficult to be impartial and value items based on their individual merits.

A combination of both approaches can also be used but be mindful of how involved the stakeholders are and whether they trust your judgement or if they need to be convinced.

Ordering Items

Ordering items implies a conversation between the Product Owner and the Development Team to discuss both the customers’ needs, the organisational priorities and the technical capabilities and dependencies to satisfy them.

Unlike prioritising which tends to be an organisation and Product Owner led conversation, ordering items considers the practical implications and limitations of delivering items to satisfy those needs, and requires the Development Team to have an opinion and can effectively express how those needs can be met. This requires a Development Team to know that they have equal say in the conversation, that their opinion matters and that they take accountability for the delivery of the product or feature.

Creating and Refining Items

Generally, in core Scrum the Product Owner is termed as the person who is responsible for managing the Product Backlog. However, this does not mean that they are the only one who can make decisions or can create new items. The whole Scrum Team should be empowered to create new items for discussion with the Product Owner.

Product Backlog Items can originate from several sources including:

• Stakeholders – who express a particular need or strategic objective
• Customer feedback – existing customers communicate their responses to existing features with critical evaluation and suggestions for improvements
• Regulatory Compliance – often external regulatory bodies will have particular compliance objectives that they need to be satisfied
• Continuous Improvements – internally derived improvements with respect to the future evolution of the product or processes
• Technical debt – cleaning and refining the technical code or components used to create the product to avoid complexity and degradation of the design
• Feature debt – cleaning and refining the feature set and user experience to remove complexity and redundant features

Refining items can involve several approaches depending on the needs:

• Splitting large items into smaller ones – often when ideas are first expressed as Product Backlog Items they can be quite large and indicate the level of abstraction or ambiguity from the detail. When more information is known from previous iterations and Sprints, then these large items can then be broken down into smaller and more manageable items that can be completed within a Sprint.
• Ambiguous items – teams that struggle to break items down into smaller items tend to lack sufficient knowledge or experience to be able to do this, and so may instead opt to create an investigation item first to gain more knowledge through experimentation and prototyping, followed by an implementation item to create the new feature with the newly acquired knowledge.
• Merging items together – items that are related and share a common approach may well be merged together to form a single item that is more appropriate.
• Superseding items – items that were initially placed on the Product Backlog as placeholders for ideas may well be superseded by new items that are more refined as new knowledge is discovered and experience is gained over time and successive Sprints.
• Discarding items – never be afraid of discarding old items that are no longer needed, as this places more emphasis on the items that remain and helps to define a clearer idea of where the true value to the customer lies

Refining items a little and often with regular gatherings of the Scrum Team to consider the Product Backlog tends to work best, as this promotes a continuous refinement and evolutionary approach to the Product Backlog.

Product Backlogs should be constantly curated as more is known and the true value to the customer becomes ever clearer.

See Also

• Scrum Framework
• Scrum Artefacts
• Product Owner
• Sprint Planning & Product Backlog Refinement
• Product Backlog Refinement
• Product Backlog Items