Practical Prioritization

I began this series of articles with a post titled “Issue Prioritization“, where I described some of the drawbacks of traditional prioritization schemes, and proposed a new scale for measuring priorities. The next post titled “Multidimensional Prioritization” explored how prioritization values could be derived a set of orthogonal factors, each of which could be measured objectively. The process for producing such prioritization values may have appeared quite daunting, especially when compared to a more typical method of subjectively assigning a number between 1 and 5. In this post, I will present methods for making the proposed prioritization process simpler and easier to implement.

Mapping ROI to Priority

Before getting into the process simplification discussion, I would like to address one other issue that came up in the previous post. As discussed earlier, the scaled ROI value is the composite of the Impact, Frequency and Scope factors. The ROI value is expected to represent a proportional measure of priority. The problem is that the scaled ROI value spans a range from -13…27, while the desired range for the priority value is 0…10. The challenge is how to best map ROI values to the desired range for priority values.

To start with, let’s revisit what the ROI value actually represents. The Return On Investment is equal to (Added Value) / (Implementation Cost). Given this, a full-scale ROI value of 1 would indicate that the implementation cost would be recouped in a one year period. For all practical purposes, any issue with an ROI of 0.1% or less would not be worth consideration. This corresponds to a scaled ROI value of -3, so any values below this level could be treated as equivalent to -3.

Similarly, issues with very high ROI values (let say of 1,000,000,000%) would be so rare that there is no point in extending the range that high. Thus the upper end of the scaled ROI range could be effectively capped at 7. This clipped range of -3…7 for scaled ROI can now be easily mapped to the target range of 0…10 for the scaled prioritization value by simply adding 3 to the scaled ROI value.

Simplifying the Prioritization Process

The one area where computers are far superior to human beings is in the capacity to perform calculations. In consideration of this, the first step toward simplifying the described prioritization process will be to shift the burden of mathematical computation to the computer. The human operator need only be responsible for entering in a few values that are relatively easy to assess, while the computer will handle the entire process of scaling, shifting and combining values to produce the final scaled prioritization value as described previously.

Ideally, the computational logic for generating the prioritization value would be integrated directly with the issue tracking system, and would thus be virtually transparent to the human operator. Lacking that, a separate application designed solely for performing such calculations could be produced and later utilized by the human operator while entering details about the relevant issue. Even a spreadsheet with a few formulas could serve as a suitable tool for calculating priorities.

For the human operator, the data entry should be limited to estimating the implementation cost and describing one or more use case scenarios, specifying the impact, frequency and scope for each. In most cases, a given issue will be limited to a single use case. For situations where multiple use-case scenarios apply, there will often be a dominant use case scenario that may overshadow the minor use case scenarios to such an extent that their inclusion will not materially affect the overall prioritization of the issue. For those situations, only the dominant use case scenario need be described.

The frequency factor will normally be the easiest of the three factors to quantify. In fact, for standard test cases, the frequency factor can be determined once when the test is defined, and then used whenever an issue arises from that test case. The value of the frequency factor is generally determined by answering the question “How often will the participant likely encounter this issue on an annual basis?” The answer will typically depend on such things as the role of the participant, the reproducible frequency of the issue and how common the use case scenario is.

Both the impact and scope factors depend in large part upon the role of the participant involved in the use case scenario. For instance, the role can directly determine the scope, as the number of participants for a given role can generally be well defined in advance. Also, for each role, an hourly rate can be predefined, and that rate used in the determination of impact.

Impact can be a little tricky to quantify since in some cases, the impact is a loss of productivity, in others it will be an increase in service costs, while in other cases it may be a loss of sales. For cases where a loss of productivity is involved, the impact can be assessed as the amount of productive time lost due to the occurrence of the issue multiplied by the hourly rate of the role of the participant. Similarly, for an issue that increases service costs, the impact can be assessed as the amount of extra time spent servicing the issue multiplied by the hourly rate for the participant.  For cases where the loss of a sale is involved, the impact is the amount of the lost sale.

Based on the foregoing, in order to adequately describe the factors involved in a use case scenario, values will need to be entered for the following fields:

Role – Type of participant involved in the use case. Typical values would be Software Engineer, QA Engineer, Project Manager and End User.

Frequency – Average number of annual occurrences on a scale of 0…10 where 0=once/1000 years and 10=once every few seconds.

Extra Time – Productive time lost or additional time required for responding to the issue. Measured per occurrence on a scale of 0…10 where 0=a few seconds and 10=1000 years.

Lost Income – Represents amount of lost revenue. Measured per occurrence on a scale of 0…10 where 0=1 cent and 10=$100 million

To produce the three factors (impact, frequency and scope) used in calculating the prioritization value, a computer would use formulas like the following:

Impact = Role.HourlyRate * ExtraTime + LostIncome

Frequency = Frequency

Scope = Role.Count

The calculation of the final prioritization value would then proceed as described previously using the three factors above in conjunction with the implementation cost estimate. While the implementation cost may not be known at the time the issue is first encountered, a reasonable placeholder estimate can be entered until a detailed analysis of the issue can be completed.


The proposed arrangement simplifies the prioritization process to the setting of five fields (role, frequency, extra time, lost income and implementation cost). While this is certainly more complex than setting a single priority value, it is still reasonably simple and provides a vastly superior model of priority. Also, many of the factor values can be determined in advance when test cases are designed, so that it is simply of matter of using those predefined values rather than attempting to quantify each ad-hoc.

Keeping everyone focused on true priorities has always been a challenge, especially when varying subjectivity and personal interests get in the way. The prioritization scheme that I have laid out in this series aims to address that challenge, providing a reliable source of accurate priorities.

About Daniel Brannon

Daniel Brannon founded OSoSLO in 2009 to provide software tools and services for business and technology professionals.
This entry was posted in Work Management. Bookmark the permalink.

Leave a Reply