Have you ever had a conversation like this:

„These are your five top priority items.“
– „Which one is the most important one?“
“All of them.”

Or something like this:

“We have to set the priority to High – all Medium or Low items will most likely not make it anyway.”
If so you’ve likely been in Priority Hell.

Priority Hell is a place where every single item is of utmost importance, where there is no clear distinction between all the “High Prio” items, where Priorities like “Very High” or “Urgent” have reared their ugly heads. Priority Hell is also a place where everything is being worked upon but nothing gets beyond “Almost done”.
Priority Hell is a scary place.

The Root of All Evil

You might ask yourself why I cast priority in such a bad light even though it is supposed to give us guidance on how to proceed where to concentrate our efforts. And you are right that priority in general terms is GOOD. Focus is also good. But avoid flailing around aimlessly in hopes of tackling the right things first. What’s bad is the way priority is implemented and used in most of the current work processes.

For the sake of this post I’ll concentrate on the implementation of priority in Rational Team Concert – acknowledging that it is used as the main choice in project tracking and collaboration inside SWG and a lot of teams already use it. However all of the critique can be applied to other tools such as MS Project or even Excel.

Now let’s look at how priority is implemented:

You usually have three options: Low, Medium and High.
Since you can assign the category freely what becomes High or Low is entirely up to you. Sound good so far? Read on.

Opportunity Cost

What prevents you from setting everything to high? Nothing – and over time there will be a lot more things on High priority that you would imagine. The reason for this – in my opinion – is that the freedom to assign everything to high alleviates the need to make a hard choice and to weigh elements against each other. Economists refer to this as opportunity cost, meaning the lost value of the option you discarded. And make no mistake – by having to choose between two elements in terms of priority makes you take into account the risk that the lower-prioritized element will maybe not make it. It’s a lot easier to just assign both to “High” priority and assume you do not have to make a choice.

Assume that you have your list of elements and got about six elements with “High” priority – which one is the most important one? Which is the second-most important?
“All of them are important, silly!” you shout in anger – but what will that get you? Your team will start on all of them in parallel either rigorously multitasking or splitting the resources across the different elements.
Following the stream of recent publications one can assume that multitasking is one of the biggest efficiency killers of the modern work era – that’s why for example Scrum dictates that no changes to the team or plan are made within the sprint and that team members are assigned to a single team only. The same with splitting resources – assuming that your workforce is not large enough to create six separate teams to work on these items you will most likely starve certain items from manpower and knowledge.

Both factors cause work to progress slower and less efficient ultimately leading to the situation where everything is “almost” or “80-90%” done but nothing is really finished!

If you are working with a small team of about four to nine people (managers excluded) it is absolutely necessary to avoid starting multiple tasks at the same time – otherwise your resources will be spread too thin. Scrum for example suggests that instead of fanning out the ENTIRE team will tackle the top priority story from the backlog before moving on to the next one.

A Question of Leadership

For that you will need a clear distinction of priorities. A ranking has to be established that also addresses the order of items within a priority.

This ranking is a mixture of both the technical need of the item and the overall business need in terms of the project.

This integration is a leadership objective that needs to be covered by the Product Owner to be successful. On most teams the Product Owner has detailled business knowledge but only limited technical insight. For a knowledge worker this is just the other way round: She understands an item on the technical level but may lack the business knowledge. Only by integrating both the business need (following customer value, strategic alignment, etc) and the technical need (architecture requirements, technical constraints, etc.) can a reasonable piority be established.

It ultimately boils down to the team, with the Product Owner in a leadership role, to steer the project to deliver the right value at the right time and not build an imaginary ivory tower.
This steering towards delivering value is what relative prioritzation can deliver.

Relative Prioritization

A team following a ranked list of elements can focus efforts on achieving the highest, unfinished element on the list before moving on. This ensures past work is actually completed before opening the next can of worms. Also you are directly following customer (or Product Owner if you will) value – achieving the most critical elements first.

Ranking – in Three Easy Steps

Okay – “Easy” might stretch the truth a little. Doing the changes is easy living them might be more challenging.

Step 1: Get rid of traditional priorities

This first step forces you to let go of traditional priorities as it effectively blocks access to and knowledge of it.

Step 2: Use the “Ranked List” view for all planning and sprints

Then set the “Ranked List” to be used as the default view so you have a clear picture of the project priorities at all times.

Step 3: Work with ranking for prioritization only

The last step is to step up on the discipline side by only addressing the top element on the list and only that.

If the element is too small – think about bundling work differently so your entire team can work at least a day on a single story.
If some people cannot contribute to an element find out why. The most common reason is lack of skill in a particular area. If so actually take this as an opportunity to do skill transfers using techniques like Pair Programming.
If the element concentrates on a single area of work but will later be integrated with other components find out how you can do a little slice of integration now. Agile & Scrum prefer doing a “vertical slice” or “End-To-End” approach by creating a sliver of integrated functionality on all layers of the project instead of big, separated chunks.

Apart from the tackling of work you will also focus on ranking new elements as they come it. If you let them rot at the end of the list – chances are they will not be picked up in time if your team follows the “Top element first” procedure diligently. By doing ranking close to the item’s creation you are also working on a fresh memory what this item was all about – thus reducing the time to remember or fetch information later.

Both parts of Step 3 will not only ensure completion of elements in the correct order it will also surface issues you might have with team skills, work package size and alignment with the “end-to-end” approach.

The Bottom Line

Traditional prioritization in the broad “High”, “Medium” and “Low” categories leads to ambiguous item priorities. Which one of the “High” priority items should be addressed first? Should all of them be addressed at the same time? Also the addition of new requirements and work items can bloat a category severely leading to the “Everything is High” syndrome.

The result is too many open work items, everything “almost done” but nothing really finished and a lot of time and resources lost on multitasking.

A way out of this situation is to do away with the traditional prioritization categories altogether and adopt ranking.
Ranking ensures that a clear and unambiguous order of work is established, items are prioritized in relation to each other and the team as the ability to focus all efforts on finishing the most important work item first before moving on to the next one.