Maximizing the Value of Your Product Backlog (Part Two)

Rate this:
Total votes: 0

Valuating and prioritizing your features

The Product Backlog is the heart of defining any Agile solution.  The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment.  This is the second of two articles that provide you with techniques for maximizing the value of the features in your Product Backlog.  The first article, Maximizing the Value of Your Product Backlog (Part One):  Gathering the full scope of requirements provides a list of common - and uncommon - sources for gathering the full scope of requirements for your solution.

This article focusses on how to assign values to the features on your Product Backlog and prioritize the list to ensure that the Agile Development Team is continuously delivering the highest business value solution to your organization.  The first step to achieving this is identifying how you measure value.

What is Valuable to You?

There is a common misconception that the prioritization of features on the Product Backlog should always be driven by dollar value with the features that are expected to deliver the largest financial returns placed at the top of the list.  Although this may be true for a commercial organization that is building a solution to increase corporate revenue, it is rare that profit generation will be the primary driver for public sector organizations. In reality, the answer to this question can differ greatly between private industry, public sector and charitable organizations.  Equally, there are variations within each sector, where some organizations place a premium on providing exceptional customer service while others focus exclusively on reducing overheads and increasing the bottom line.  

That is why the definition of value in any Agile project should always be driven by the Product Vision, the overarching statement that defines how your solution will support the objectives of your organization.  The Product Vision will help you to identify the primary drivers that define success for your project that most commonly fall into one or more of the following categories:

  • Increasing profits
  • Reducing overhead costs
  • Reducing delivery time
  • Reducing risk
  • Ensuring customer/stakeholder satisfaction
  • Delivering innovation
  • Eliminating waste
  • Reducing complexity
  • Improving quality.

If you use your Product Vision to determine what subset of these benefits are most relevant to your project, you can establish the foundation for valuating features based on the extent to which they deliver each benefit.  The key question is how to measure the level of benefit that each feature delivers, especially when the benefit is qualitative (like user satisfaction) not quantitative (like revenue earned or time saved).

How Do You Measure Value?

Value is a relative assessment.  Although some organizations will go through the effort to gather baseline metrics or undertake extensive market research to assign dollar values to features, it is rare that the items on your Product Backlog can be definitively quantified.

An alternative approach is to use the same Fibonacci series that is used in Planning Poker to assign relative values to your Product Backlog features.  To achieve this, have each key stakeholder assign one of the following numbers to each feature in your Product Backlog:  1, 2, 3, 5, 8, 13, 21, 34, 100 with higher numbers representing higher business value.  Compile the assigned numbers for each feature across the stakeholders and put the ones that have the cumulatively highest value at the top of your Product Backlog with the other features in top down order beneath them.

Another alternative is to have stakeholders assign one of the following priorities to each feature: 

  • Important
  • Critical
  • Most Critical

These are deliberately non emotive descriptors that allow for relative prioritization without the need to relegate features to Medium or Low priority.  Once these priorities have been assigned, do a weighted calculation where Important features are assigned a value of 5, Critical features are assigned a value of 10 and Most Critical features are assigned a value of 20. Then use the approach above to put the features in top down priority order on your Product Backlog.

The most important thing to remember is that priority setting in an Agile environment is an emergent process.  Priority assignments can be adjusted as the project progresses to reflect the most current information available.  Similarly, identifying the Minimum Viable Product (MVP) for release assures the Product Owner that all essential features will be included regardless of their relative priority.  This alleviates the need for Product Owners to seek perfection in their initial priority assignments and to focus instead on providing the Agile Development team with the details they need to build the most effective solution.

Comments

Join the Discussion

Shopping cart

View your shopping cart.

Related training courses

BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page. 

BPM 101Agile Business Analysis 101Decision Management and Business Rules 101Methodologies and Approaches for BPMOpEx 101View the Learning Path for more courses »

Business Process Management Jobs