After justifying and confirming the value of a project, the Product Owner should consider the organizational policies, procedures, templates, and general standards dictated by the Scrum Guidance Body (or similar organizational project board or office) when planning a project; at the same time maximizing Value-driven Delivery.
The onus for determining how the value is created falls on the stakeholders (sponsor, customers, and/or users), while the Scrum Team concentrates on what is to be developed. Some common tools recommended by a Scrum Guidance Body might include the following:
Value Stream Mapping
Value Stream Mapping uses flowcharts, to illustrate the flow of information needed to complete a process. This technique may be used to streamline a process by helping to determine non-value-added elements.
Customer Value-based Prioritization
Customer Value-based Prioritization places primary importance on the customer and strives to implement User Stories with the highest value first. Such high value User Stories are identified and moved to the top of the Prioritized Product Backlog.
A team can use a variety of prioritization schemes to determine high-value features.
Simple Schemes
Simple schemes involve labeling items as Priority “1”, “2”, “3” or “High”, “Medium” and “Low” and so on. Although this is a simple and straightforward approach, it can become problematic because there is often a tendency to label everything as Priority “1” or “High”. Even “High,” “Medium,” and “Low” prioritization schemes can encounter similar difficulties.
MoSCoW Prioritization
The MoSCoW prioritization scheme derives its name from the first letters of the phrases “Must have,” “Should have,” “Could have,” and “Won’t have”. This prioritization method is generally more effective than simple schemes. The labels are in decreasing order of priority with “Must have” features being those without which the product will have no value and “Won’t have” features being those that, although they would be nice to have, are not necessary to be included.
Monopoly Money
This technique involves giving the customer “monopoly money” or “false money” equal to the amount of the project budget and asking them to distribute it among the User Stories under consideration. In this way, the customer prioritizes based on what they are willing to pay for each User Story.
100-Point Method
The 100-Point Method was developed by Dean Leffingwell and Don Widrig (2003). It involves giving the customer 100 points they can use to vote for the features that they feel are most important.
Kano Analysis
The Kano analysis was developed by Noriaki Kano (1984) and involves classifying features or requirements into four categories based on customer preferences:
- Exciters/Delighters: Features that are new, or of high value to the customer
- Satisfiers: Features that offer value to the customer
- Dissatisfiers: Features which, if not present, are likely to cause a customer to dislike the product, but do not affect the level of satisfaction if they are present
- Indifferent: Features that will not affect the customer in any way and should be eliminated
