Problem solve Get help with specific problems with your technologies, process and projects.

How to set priorities: A software project team exercise

Everyone on a software project team struggles at times with setting priorities. Our requirements expert offers advice for effective prioritization.

What do we do when everything is high-priority?

Everyone who has worked on a software project team has seen what a prioritized list of requirements looks like. On the list, two-thirds of the requirements are "must-haves," most of the rest are "should-haves," and a few are "that would be nice" requirements, and no one expects them to be done. Someone's name will pop into your head when I describe the following inner monologue: "I'll make sure this requirement stays near the top of the list -- even though I don't care about it. I can sacrifice it later and still end up with the deck stacked in my favor, even after compromising." I wish this behavior only happened in Mark Twain novels. Almost every prioritization exercise that groups requirements by importance into buckets heavily over-indexes to the most important bucket.

And that's not particularly unreasonable. Every idea that makes it into the conversation is an important one. They filtered out most of the stuff that isn't worth doing. The problem (with some colorful exceptions) is not the people -- the problem is in using buckets to prioritize. Thankfully, there are two solutions project managers can implement when setting priorities. One of them is easier to do; the other is more useful.

The easiest solution is to split the high-priority requirements into thirds. Just label them A, B and C, because you're risking sliding down a slippery slope if you introduce really "high," "extremely high" and "atmospherically high" categories. It's grade inflation for the flawed priority-bucket model. Explain to team members that you're doing this because the size of the current bucket is too large to be useful. You'll still end up with half or more of the high-priority requirements being classified as A requirements. In effect, you've now got about one-fourth to one-third of your requirements in the "most important" bucket and some additional information in the "next most important" bucket. This gives you some value without having to convince people to rethink their flawed approach. Sometimes there's too much urgency in other areas to invest in changing culture and fixing a broken process. This will help some and you'll live to fight another day.

The more useful solution is to get software project team members to put the items from the overly-large must-have bucket into relative order. There's an innovation game called 20/20 Vision that does exactly this. The name comes from the dialogue from an optometrist visit: "Is it better like this, or better like this?" You force your team of stakeholders to take the items and agree on their relative importance. That's actually a lot more useful than just having big buckets.

There are two sneaky reasons why it is surprisingly easy to get people on a software project team to do this. First, you'll want to do this with physical objects -- write IDs or short names for each item onto Post-it notes or index cards. Then, lay them out in order from highest to lowest priority (on a table, on the wall, or wherever). Using physical objects makes the exercise more engaging for people and it triggers more effective conversations, or debates, when people disagree about the relative importance of some items.  

Second, you've shifted the conversation away from, "Will feature X make it into the release?" That's a dangerous conversation, because that's where agendas and fears come out. Setting priorities is not a "plan the release" exercise; it is a "find out what is important" exercise. When you get people into the mindset of, "Just put them in order," the process starts to work and you get information.  

One question that always comes up is, "What do we do about ties?" The answer is that ties aren't allowed; you have to pick one. If you allow ties, you'll end up with a bunch of five-way ties and people will switch back into a bucketing mindset. Most of time, teams will have one to three ties that come up with a group of a couple dozen items. The rest of the decisions seem to be surprisingly easy for them as much information was just waiting to be exposed.

Another question that comes up occasionally is, "Why are we wasting our time doing this when all of these items must get done?" This question comes from either naiveté, misplaced motivation or just the need to be a bully. I've had success with the following response: I've got five developers on the team, and their estimate is that they will just barely get all of these items done. If one of them quits tomorrow, the stuff that doesn't get done are the items at the bottom of the list. The team is going to work from the top down. If you want input on which items are at greatest risk and which are the surest things, participate in the exercise. If you don't, the list will be in a random order -- but you'll still work from the top down. If you put things in order, you'll learn a lot more about what is truly important than if you put them in buckets.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.