Your guide to create a Scrum Prioritized Product Backlog
In this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point.
User Story Prioritization Methods
Some techniques used to prioritize the User Stories or requirements in 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 “Would like to have, but not at this time.” 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 “Would like to 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:
1. Exciters/Delighters: Features that are new, or of high value to the customer
2. Satisfiers: Features that offer value to the customer
3.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
4. Indifferent: Features that will not affect the customer in any way and should be eliminated
Prioritized Product Backlog*
The Product Owner develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of Epic(s), which are high level User Stories. The Prioritized Product Backlog is based on three primary factors: value, risk and uncertainty, and dependencies. It is also referred to as the Risk Adjusted Product Backlog since it includes identified and assessed risks related to the project. It also encompasses all Approved Changes that can be appropriately prioritized in the Prioritized Product Backlog.
• Value—It is the Product Owner’s responsibility to ensure delivery of those products that provide the highest level of business value first. Even an extremely valuable product may not be part of the first release if there are other products of even higher value that are sufficient for a first release.
• Risk and Uncertainty—The more uncertainty that exists, the riskier the project is. Therefore, it is important that riskier products in the Prioritized Product Backlog are given higher priority. Products carrying a higher level of risk will also require risk mitigation actions. When these risk mitigation actions are prioritized against the backlog, the result is a Risk Adjusted Product Backlog. Dealing with risks early in the project does not guarantee that the project will be successful, but it does enhance the team’s ability to deal with risk.
• Dependencies—It is usually not possible to create a Prioritized Product Backlog in which there are no dependencies between User Stories. Functional requirements often depend on other functional and even non-functional requirements. These dependencies can impact how the User Stories in the Prioritized Product Backlog are prioritized. Two of the most common ways to resolve dependencies are to either split a single story into multiple parts or combine interdependent stories.
• Estimates—High level estimates for Epic(s) are also available in the Prioritized Product Backlog.
