Relative Prioritization or Ranking
From AgileBok.org
Virtually every time management system teaches that you must prioritize your projects to make sure you’re working on what’s truly important instead of getting caught up in minor things. However, few systems explain precisely how to do this. How do you decide which task is really the most important at any given time? Is it the one that’s most urgent, the one that will earn you the most money, the one that will produce the greatest long-term happiness, the one that will please your boss the most? If you don’t use an intelligent method of prioritization, you’ll lack consistency and bounce from one task to another with no rhyme or reason.
Relative Planning, Ranking, and Priorities
You use planning, ranking, and priority fields to specify which work the team should complete first. If you rank user stories, tasks, bugs, and issues, all team members gain an understanding of the relative importance of the work that they must accomplish. Ranking and priority fields are used to build several reports.
You rank and prioritize work items when you review the backlog for a product or an iteration. For more information, see Rank the Product Backlog and Iteration Backlog.
Relative Weighing for User Story Prioritization
Relative weighting is a prioritization approach that considers both the positive benefit of the presence of a feature and the negative impact of its absence. Each theme or epic being considered for the next release is assessed in terms of the benefits it will bring if implemented and the penalty that will be incurred if it is not implemented. The benefit and penalty for each theme or epic are assigned values from 0 (low) to 9 (high).
Check out Free Relative Weighing Tool. To use this worksheet, add as many rows as you have themes or epics to consider. Enter a value from 0-9 into the relative benefit and penalty columns for each. Then enter an estimate of the development effort for each in that column. Estimates can be given as story points, ideal days, financial amounts, or any other value.
Relative Ranking to Prioritize User Stories==
Prioritize the User Stories: Your product owner prioritizes the user stories in the product backlog by working with your customers to understand what they value and by working with your team to understand risks and dependencies. Your product owner specifies priorities by assigning a rank to each user story to indicate the order in which the team should implement them.
Your product owner can use many techniques to analyze and compare the value of user stories. If your team already has a method for prioritizing that works well for you, use that method.
A few prioritization techniques are closely associated with the agile community, such as the Kano model of customer satisfaction and relative weighting by Karl Wiegers. (For more information about relative weighting, see the following page on the Web: First Things First: Prioritizing Requirements.) Other prioritization techniques, such as cost prioritization, net present value, payback period, and internal rate of return are well established outside the agile community. These techniques are also legitimate and appropriate for prioritizing your product backlog on a Scrum project. For more information, see "Part II: Estimating Size" from the book that the following Web resource identifies: Agile Estimation and Planning.
Relative Ranking to Estimate User Stories
Your team collaboratively estimates each user story in story points. In his book "Agile Estimation and Planning," Mike Cohn defines story points this way: "Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work." Story points are relative values that do not translate directly into a specific number of hours. Instead, story points help a team quantify the general size of the user story. These relative estimates are less precise so that they require less effort to determine, and they hold up better over time. By estimating in story points, your team will provide the general size of the user stories now and develop the more detailed estimation of hours of work later, when team members are about to implement the user stories.
Eight Steps to Relative Prioritization
Step 1. List All of the Requirements
List all of the requirements, features, or use cases that you wish to prioritize in a spreadsheet===
We’ll use features in this example. All of the items must be at the same level of abstraction. For example, don’t mix individual requirements with product features. If certain features are logically linked (that is, you would only implement feature B if feature A were included as well), include only the driving feature in the analysis. This model will work with up to several dozen features before it becomes unwieldy. If you have more items than that, abstract related features together to create a more manageable initial list. You can do a second round of analysis at a finer granularity of requirements detail if you need to.
Step 2. Estimate the Relative Benefit
Estimate the relative benefit that each feature provides to the customer or the business on a scale from 1 to 9, with 1 indicating very little benefit and 9 being the maximum possible benefit. These benefits indicate alignment with the product’s business requirements. Your customer representatives are the best people to judge these benefits.
Step 3. Estimate the Relative Penalty
Estimate the relative penalty the customer or business would suffer if the feature is not included. Again, use a scale from 1 to 9, where 1 means essentially no penalty and 9 indicates a very serious downside. For example, failing to comply with a government regulation could incur a high penalty even if the customer benefit is low, as would omitting a feature that any reasonable customer would expect, whether or not they explicitly requested it. Requirements that have both a low benefit and a low penalty add cost but little value; they may be instances of gold plating.
Step 4. The Total Value Column
The Total Value column is the sum of the relative benefit and penalty. By default, benefit and penalty are weighted equally. As a refinement, you can change the weights for these two factors. In Table 2, all benefit ratings are weighted twice as heavily as the penalty ratings. The spreadsheet totals the feature values and calculates the percentage of the total product value provided by these features that is attributable to each feature.
Step 5. Estimate the Relative Cost
Estimate the relative cost of implementing each feature, again on a scale ranging from a low of 1 to a high of 9. The spreadsheet will calculate the percentage of total cost for each feature. Developers estimate the cost ratings based on factors such as the requirement complexity, the extent of user interface work required, the potential ability to reuse existing designs or code, and the levels of testing and documentation needed.
Step 6. Estimate the Relative Degree
Developers estimate the relative degree of technical or other risk associated with each feature on a scale from 1 to 9. An estimate of 1 means you can program it in your sleep, while 9 indicates serious concerns about feasibility, the availability of staff with the needed expertise, or the use of unproven or unfamiliar tools and technologies. The spreadsheet will calculate the percentage of the total risk that comes from each feature.
By default, cost and risk are weighted equally, and each carries the same weight as the benefit and penalty terms. You can adjust the cost and risk weightings in the spreadsheet. In Table 2, risk has one-half the weight of the cost factor, which has the same weight as the penalty term. If you don’t want to consider risk in the model, set the risk weighting value to zero.
Step 7. Calculate Priority Number
Once you enter the estimates into the spreadsheet, it calculates a priority number for each feature. The formula for the Priority column is:
priority = value %/ (cost % * cost weight + risk % * risk weight)
Step 8. Sort the List of Features
Sort the list of features in descending order by calculated priority. The features at the top of the list have the most favorable balance of value, cost, and risk, and thus should have higher implementation priority. The key customer and developer representatives should review the completed spreadsheet to agree on the ratings and the resulting sequence.
Conclusion
Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.
