At the program or portfolio level, there is normally a smaller number of requirements/user stories than at the project level. The percentage of user stories with a very tangible value/business need/user impact is normally much lower than on project level. That means that the selection of techniques that are useful at a program or portfolio level will be smaller. For example, Kano analysis has limitations because there won’t be any dis-satisfiers or exciters. Without a significant number of stakeholders, especially users, the 100-point method has limited value. The MoSCoW technique also has limitations because there won’t be any “nice to have” or “Won’t have” features at program and portfolio levels.
Some techniques used to prioritize the User Stories or requirements in the Prioritized Product Backlog, on the basis of business value are presented below:
- MoSCoW Prioritization scheme—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” User Stories being those without which the product will have no value and “Won’t have” User Stories being those that, although they would be nice to have, are not necessary to be included.
- Paired Comparison—In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.
- 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 User Stories that are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.
- 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
Kano Analysis
Interestingly, features usually move down the classification list over time; customers will come to expect features (e.g., cameras on phones) and these features will move from being exciters/delighters to satisfiers and eventually to dissatisfiers.
At the program or portfolio level, there is normally a smaller number of requirements/user stories than at the project level. The percentage of user stories with a very tangible value/business need/user impact is normally much lower than on project level. That means that the selection of techniques that are useful at a program or portfolio level will be smaller.
