Articles

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 Epics, User Stories, or requirements in the Prioritized Product Backlog, based on 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” features or functionalities being those without which the product will have no value and “Won’t have” functionalities being those that, although would be nice to have, are not necessary to be included.

• Paired Comparison—In this technique, a list of all the Epics/User Stories in the Prioritized Product Backlog is prepared. Next, each Epic/User Story is taken individually and compared with the others in the list, one at a time. Each time two Epics or User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of Epics or 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 Epics or User Stories that are most important. The objective is to give more weight to the Epics/User Stories that are of higher priority when compared to the others. 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 Epic or User Story.

• Kano Analysis — TThe 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. 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
3. Satisfiers: Features that offer value to the customer
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 Epics, which are high-level User Stories. The Prioritized Product Backlog is based primarily on three factors—value, risk or uncertainty, and dependencies. It may also be referred to as the Risk Adjusted Product Backlog since it includes identified and assessed risks related to the project. The Prioritized Product Backlog also encompasses all the approved changes that can be appropriately prioritized .

• Value—The Product Owner is responsibility to ensure the delivery of Epics or those product increments or functionalities that provide the highest level of business value first. Even an extremely valuable product increment may not be part of the first release if there are other product increments of even higher value that are sufficient for a first release.

• Risk and Uncertainty—The more uncertainty that exists, the riskier a project will be. Therefore, it is important that riskier Epics in the Prioritized Product Backlog are given higher priority. Requirements carrying a higher level of risk will generally require risk mitigation actions. When risks and their corresponding risk mitigation actions are considered and prioritized against other backlog items, the result is a Risk Adjusted Product Backlog. Dealing with risks early in the project does not guarantee that a project will be successful, but it does enhance the team’s ability to successfully deal with those risks.

• Dependencies—Most projects will inherently have dependencies between some of the Epics or User Stories. These dependencies should be taken into consideration while creating the Prioritized Product Backlog. Functional requirements often depend on other functional and even non-functional requirements. These dependencies can impact how the Epics (and User Stories) in the Prioritized Product Backlog are prioritized. Two of the most common ways to resolve dependencies are to either split a single Epic (or User Story) into multiple Epics (or User Stories) or combine the interdependent portions.

• Estimates—High-level estimates for Epics generated from the estimation methods are also available in the Prioritized Product Backlog.