It is not advisable to go straight from the Product Vision to collecting requirements for the Product Backlog.

The Product Owner (PO) is solely responsible for the value produced by a Product Development and to have some understanding of this value the Product Objectives, Benefits and an initial Business Case should be investigated to check that, in all probability, the product will produce value for the company; it is no good having a great product if no one will buy it and/or it will take 5 years to recoup the development costs.

To help the Product Owner and Development Team move from the Product Vision to the Product Backlog, as a Scrum Master, you can arrange a series of facilitated workshops to DETERMINE the Product Objectives, Business Case and Backlog.

Product Objectives

The Product Objectives are a list of things that enable the meeting of the Product Vision. It should not be a long list; between 5 and 10 is usual; Objectives are not requirements.

Some examples:

• “MVP to be released for the Christmas MARKET”
• “Reduce report creation time by a minimum of 50%”
• “Increase re-registrations by 50% in 1 year”

Although a Product Vision may state some development attributes that can be measured, most do not; it is the Objectives that should be measurable.  Some people use S.M.A.R.T Objectives.

The Objectives list may also be ordered by business value and may define what is to be included in a Minimum Viable Product (MVP).

Benefits

From the Objectives list, we can now make an ESTIMATE of the expected benefits that we expect the product to give to the ‘customer’ (internal and/or external) and the company; each Objective may contribute to more than one category of Benefit; for example, an Objective of “Reduce report creation time by a minimum of 50%” may have the following Benefits:

• Allow Marketing Dept to make faster pivot decisions:
• Less rework: expected savings = 20% of marketing costs
• More timely information
• Reduced customer frustration: increased customer re-registrations revenue = 50% 
• Reduced staff frustration: reduced staff turnover and recruiting/training costs = 20%

Although we have USED percentage values in the examples above, it is recommended that actual monetary values are used.

• Business Case

Now that we have the expected Benefits from developing the product, we must now estimate how much it might cost to develop.

At this point, the Development Team may not have been chosen:

• We may outsource the development
• We may not have chosen the technology to be used
• The potential Team may be busy finishing another product development

To help the PO create an initial Business Case, as the Scrum Master, arrange a facilitated workshop to include the PO, relevant stakeholders and senior ‘technical’ personnel to investigate the PROBABLE costs of:

• Configuring something that already exists
• Developing the product in-house
• Different implementation technologies
• Hiring contracting staff to cover skill shortfalls
• Outsourcing part or all the development
• Doing nothing: Although the immediate cost of doing nothing is zero, doing nothing now may have significant costs in other areas of the business

From these investigations, the workshop participants must decide as to which option will give, potentially, the best value.

The costs of the potential solution option must be compared with the expected benefits to make a cost-benefit decision as to whether the proposed product development is worthwhile.

See the APM website and other websites for more detailed information and ideas.

• Product Backlog

Once the Business Case has been approved, the PO can turn his/her attention to creating the Product Backlog.

As the Scrum Master, organise a facilitated workshop to include the PO, relevant stakeholders and the Delivery Team to discover the Product Backlog Items (PBI), usually User Stories, that will fulfil the Product Objectives.

These PBI will be estimated by the Development Team and the results fed back into the Business Case to ensure that the cost-benefit analysis still indicates a viable development.