Software development is driven almost entirely by priorities. Executive managers set priorities for product lines. Product managers set priorities for feature development. Development managers set priorities for tasks. Project managers set priorities software bugs. In turn, software engineers focus on the highest priority tasks and bugs assigned to them. When prioritization is done well, it ensures that everyone is focused on work that will maximize their possible contributions. Conversely, inadequate prioritization can result in misdirected attention, significantly impeding progress toward a company’s goals.

While prioritization exists at all levels in a software organization, it is often most visible in defect tracking and project tracking systems. Here numeric values are often assigned to issues to represent priority levels. In a typical prioritization scheme, the highest priority issues might be represented by the number 1, while the lowest priority issues are represented by the number 5. Usually, only whole numbers between these values are permitted. While such a prioritization scheme is simple to implement and use, it suffers from some serious deficiencies which hamper its effectiveness.

Such a prioritization scheme relies heavily upon subjectivity. The individual responsible for setting the priority must make an educated decision based on the facts of the issue to determine an appropriate priority level. The problem with this is that it provides too much freedom for personal choice to intervene. No two individuals are likely to prioritize a given set of issues in the same way. Each will be swayed by personal preferences, office politics and other distractions from the goal of proper prioritization.

Another significant problem is the use of discrete priority buckets. In the example prioritization scheme, there are five priority buckets (numbered 1 through 5). All priority 1 issues get put into the same bucket. When a software engineer is ready to start a new task, if there are multiple issues in the priority 1 bucket, then the engineer can arbitrarily choose one. Again, the problem here lies in having too much personal choice freedom in the process. The software engineer may choose an issue based on factors entirely unrelated to maximizing productivity, thus thwarting the prioritization goals.

Prioritization schemes, such as the one discussed here, cannot adequately represent the true dynamic range of prioritization values. A software bug that is actively wiping out all data on the hard drives of millions of customers is a billion times more important than an off-by-one-pixel UI bug. Yet there is no way to express such an extreme prioritization difference when the scheme is limited to a handful of whole numbers.

Finally, the example prioritization scheme uses reverse numbering, where 1 is highest priority and 5 is lowest, even though 5 is a higher number than 1. While not all prioritization schemes suffer from this problem, it is a commonplace arrangement and can be a source of confusion.

In order for a prioritization scheme to avoid the problems outlined above, it would need to meet the following criteria:

- The prioritization value must be set based solely on objective factors
- The set of possible prioritization values must be continuous (or nearly so)
- The possible range of prioritization values must span several orders of magnitude
- Higher priority values would be numerically higher

To design a better prioritization scheme, I’ll address each of the above criteria beginning with the last one (since it is the easiest). All that is necessary to ensure that higher priority values are numerically higher is to reverse the priority order in the previous example. So, in the new scheme, 1 represents the lowest priority, while 5 represents the highest.

Moving on to address the possible range of prioritization values, the range 1…5 certainly does not span several orders of magnitude. That can easily be fixed by changing the range to 1…10,000,000,000, which spans 10 orders of magnitude.

The criterion for having a continuous set of possible prioritization values is an attempt to limit the cases where two issues have identical priority values. Such cases introduce ambiguity in the decision of which issue to address first. In practice, using at least 100 discrete priority buckets will sufficiently approximate a continuous value set, and will prevent duplicate priority values in most cases. Even when duplicate priority values are encountered, the actual difference in true priority of the affected issues will be so small, that it should not matter significantly as to which issue is addressed first.

The next problem is how to distribute the priority buckets over the range of possible values. If the 100 buckets are distributed at evenly spaced intervals (every 100,000,000), then the lower 8 orders of magnitude will contain a single priority bucket, while the highest order of magnitude will contain 90% of the priority buckets. A better distribution would be one in which each order of magnitude of prioritization values contains the same number of priority buckets. To accomplish this, the following formula could be used to determine the prioritization value of each bucket:

P_{x} = 10^{(x/10)}, where x = 0…100

Using this distribution scheme, the first ten priority values would be:

- 1.00
- 1.26
- 1.58
- 2.00
- 2.51
- 3.16
- 3.98
- 5.01
- 6.31
- 7.94

Each subsequent set of ten priority values would be a factor of 10 greater than the previous set of priority values. When plotted on a logarithmic scale, the set of prioritization values will form a straight line as shown in the chart here:

The main problem remaining with this scheme is the prioritization values themselves. In the extreme case, they could reach as many as eleven digits in length. Even the mid-range values are about six digits long. In any case, such large numbers are difficult to deal with, both in the data entry aspect as well as when evaluating and comparing values. Humans are generally more comfortable with smaller numbers.

To make the prioritization values more manageable, we can transform them to the logarithmic scale (base-10). With this scale, the prioritization values would span the range of 0.0…10.0, and would be evenly spaced at intervals of 0.1. This is exactly like how earthquake magnitudes are represented. In this scale, a prioritization value of 6.5 would be considered to be ten times higher priority than a value of 5.5.

The proposed prioritization value scheme produces manageable 1-3 digit values, using a familiar logarithmic scale to represent a wide dynamic range. It also uses higher numeric values to represent higher priorities, and has a sufficient number of discrete priority buckets to approximate a continuous value set.

The only criterion remaining to be addressed is where the prioritization value must be set based solely upon objective factors. For now, I will leave the discussion of that criterion for a later post.

Pingback: Daniel Brannon Consulting » Practical Prioritization