The Product Backlog Hinders Value Creation – Part 3

In part 2 we looked at how an improved value process can rectify the shortcomings of a Product Backlog / User Story oriented standard agile approach. The main component was introducing two levels of quantified goals; Stakeholder Goals and Product Goals and evaluate ideas and real implementations against those goals, particularly the Product Goals.

Now, it’s time for some specific, although simplified, examples. Imagine a clothes shop that also sells through their web site.

Stakeholder Goals

Stakeholder Goals aim at identifying who it is that needs something to be improved, and what that improvement is for them. For example:

Sales Manager Double the revenue from sales through web site within a year after release
Operations Manager Reduce the Operations and Maintenance costs related to this web site by 50 % within a month after final release
Web site editor Reduce effort spent publishing new clothing items by 50 % within a year after release

The point is – identify the major stakeholders and find out what’s valuable for them.

Product Goals

The Stakeholder Goals then need to be transformed into Product Goals – qualities that the product should have in order to fulfill the Stakeholder Goals. Examples:

Product Goal Name: FindItem.Fast
Gist: The user should spend as little time as possible finding the clothing item she wants.
Scale: The time it takes a user to find the clothing item she wants. Average, in seconds.

Product Goal - Baseline and Goals

The important thing is to construct a scale, a way to measure the important qualities, so that the effect of design ideas and implementations can be either estimated or actually measured. Once the scale is in place, we can set a baseline and goal, as well as noting an “acceptable” level, in case we don’t get all we want on all the various Product Goals.

In this example, also note how the focus shifts from simple functionality to a more usability-ish approach, including a usability-like test. Some more examples:

Product Goal Name: Maintenance.ReduceEffort
Gist: Operations and Maintenance costs should be as low as possible
Scale: The time it takes an operator to find and fix a simple error, including stopping and starting the system. Average, in minutes.

Product Goal Name: PublishItem.ReduceEffort
Gist: Editors should spend as little time and effort as possible publishing new clothing items.
Scale: The time it takes an editor to publish a new clothing item, including verifying and possibly fixing appearance on web site. Average, in seconds.

With 10-12 goals like this, we have a really good foundation for steering the project towards creating real value for the customer. Also, keep in mind that the primary use of the goals is to set direction and help prioritize what to do next – it is not to measure success.


Now, if we can do this, use the improved Value Process centered on quantified goals, I see at least three huge benefits compared to the standard Product Backlog-centered approach.

  1. Everybody knows what is valuable – “value” is made explicit. We no longer have to look behind the Product Backlog, or ask “why” multiple times, in order to figure out what the customer finds valuable. It’s right there, in our face, giving the customer and the developers a very potent tool for evaluating ideas and implementations, prioritizing and basically steering the project in the best possible way.
  2. It’s easier to manage the Product Backlog. The Product Backlog is no longer an exhaustive list of functionality to implement that has to be constantly prioritized. Instead it’s a (usually) much shorter list of ideas, all of which are not going to be implemented.
  3. We utilize a much larger group of brains to find the good solutions. The customer is no longer alone in her task to find good ways to create value through the project. The developers are no longer limited to just finding good ways to implement a set of user stories. Instead, the customer invites the developers to use their impressive creativity and problem-solving skills to find good ideas for how to reach the goals. The developers go from functionality-implementers to goal-seekers, from implementing means to finding means. Besides resulting in better ways to reach the goals, there are so many positive secondary effects, especially with regards to motivation and collaboration, that one really should not underestimate this benefit.


In part 1, I looked at three problems with the Product Backlog as a tool for creating value. In part 2, I rose one level and looked at the flawed Value Process centered on the Product Backlog, and proposed an improved Value Process centered on quantified Goals. In this final part, part 3, I gave simple examples of Stakeholder Goals and Product Goals, as well as the benefits to gain from working this way.


I did not make up all of this myself (now, there’s a surprise!). The improved Value Process is basically Evo, created by Tom Gilb as early as the 1960’s, and first published in his book “Software Metrics” in 1976. Tom has developed Evo further, working with his son Kai for the past 20 years or so. You should check their web site, – a treasury of papers, presentations and book chapters and, of course, the authorative source on Evo. The Gilbs are very open with all of their material.

Also, Ryan Shriver has a nice web site called The Agile Engineer, with several good papers and presentations on how this value focus can work with Scrum.

This entry was posted in Agile, Scrum, value and tagged , , . Bookmark the permalink.

One Response to The Product Backlog Hinders Value Creation – Part 3

  1. Pingback: The Product Backlog Hinders Value Creation – Part 2 « Leaning Agile

Leave a Reply

Your email address will not be published. Required fields are marked *