Backlog Refinement Takes You from Vision to Value

by Ellen Gottesdiener and Jeff Sutherland

Deliver Value Sooner

Backlog refinement prepares your backlog for development. Investing in doing this well helps you deliver value sooner, can double your productivity, and builds strong collaboration—the backbone of high performance teams. We find that Product Owners need advanced training in backlog refinement. With a keen focus on value and conducting Structured Conversations using the 7 Product Dimensions, you greatly improve your ability to go from vision to value.

Refinement Is about Readying

Refining the product backlog involves analyzing and slicing stories in a way that makes backlog items ready for sprint planning. A healthy backlog is continually refined by the product owner for the team to detail, estimate, value, and order backlog items. This ongoing refinement work is the key for rapid and incremental delivery of product value while optimizing the productivity of the development team. According to studies performed by Jakobsen and Sutherland, product backlog items that have been properly refined in time for sprint planning can double a team’s productivity. [1]

Yet, teams struggle to efficiently and effectively do this important work. They falter when they waste time on backlog items that are insignificant to the overall value of the product or are too big or fuzzy to be actionable or demonstrable.

Start and End with Value

A successful product delivers value when it is aligned to your product vision and goals. A product delivers value when it provides a fair return in exchange for time, money, goods, or services. Refinement assumes that the product owner collaborate with the development team to order the backlog based on value. And refinement requires tough decisions that balance different stakeholder perspectives of value with how value changes over time based on evolving market conditions and customer need.

Value-based backlog refinement decisions require collaboration between the product owner and the team. Building trust should reveal the complexities that influence the inevitable trade-offs needed throughout the development life-cycle. Some sprints, for example, might require the team to take on short-term technical debt to deliver features needed to stay on par with other product offerings in a highly competitive market. Other sprints might require the team to focus on reducing the risk of regulatory noncompliance by deferring work on desirable features to a later sprint.

Taking a Holistic View of Backlogs

Every product and associated backlog items have 7 Product Dimensions that incorporate functional requirements (User, Action, Data, Control dimensions) and nonfunctional requirements (Interface, Environment, Quality Attribute dimensions). [2]

The 7 Product Dimensions provides a unified, complete, and comprehensive understanding of the product under development. This holistic view of backlog items emphasizes that no single dimension is sufficient by itself—all seven are necessary. By exploring these dimensions, everyone’s understanding of backlog items should benefit from improved conversations.

Structured Conversations Help You Slice for Value

The team needs a mechanism to encourage exploration, evaluation, and confirmation while backlog items are being refined. This ongoing and systematic approach is called the Structured Conversation.

The concept of a Structured Conversations is a useful tool for group collaboration and innovation. It encourages a more efficient approach for exploring, evaluating, and confirming options.

Initially, the team explores options for backlog items across the 7 Product Dimensions. The team then evaluates a subset of high value options and assembles them into cohesive valuable chunks. The conversation is not over until everyone knows how to confirm their shared understanding by identifying how each story will be demonstrated and validated.

Refining using Structured Conversations with the 7 Product Dimensions exposes dependencies and enables the team to focus on actionable, valuable stories that are small enough to be estimated and completed within a sprint. Enabling specifications are often byproducts of these conversions that supplement more complex stories. [3] Enabling specifications can include wireframes (Interface dimension), data model diagrams (Data dimension), decision tables (Control dimension), or similar visual analysis models. As a case in point, the team should prioritize creating enabling specifications that are most useful for regulatory compliance, reference information for product support, and for team members who don’t have domain knowledge.

We have developed an additional two days of training beyond the Scrum Inc Scrum Product Owner and Scrum Inc Scrum Master course to help those doing product backlog refinement take their story making to the next level. Better stories means faster delivery, greater customer satisfaction, and higher team happiness and motivation.

Want to Learn More?

Read the book Discover to Deliver: Agile Product Planning and Analysis by Ellen Gottesdiener and Mary Gorman.

References
1. Jakobsen, C.R. and Jeff Sutherland, J. “Scrum and CMMI—Going from Good to Great: Are you Ready-Ready to be Done-Done?” Agile Conference, IEEE Conference Publications (2009): 333-337.
2. Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting. 2012.
3. Sutherland, Jeff. “Enabling Specification: The Key to Building Agile Systems.” Scruminc (blog). June 2, 2012.