Priorities – part 2

In my last post, I started my rant on the failures of prioritization. Prioritizing bugs is bad enough, but prioritizing features can be much, much more difficult.

Here's an example from my past of how feature prioritization works. First, marketing and program management talk to customers, users, designers, researchers, usability specialists, and whoever else they think may have good input into the features needed for the upcoming product (or version of a product). On larger projects, this is done separately for each area of the project. When they're done with the idea gathering game, they put all of the ideas into a big spreadsheet.

At this point, program management, executive leadership for the project, and other key decision makers typically meet and prioritize the features. Key strategic features are marked as Priority 1 (these have to be done no matter what!). Most of these require lengthy discussion and debate on why they deserve the priority 1 label.

Priority 2 features are comprised of all features that lost the argument to become Priority 1 features. It is often a strategic move to have the priority 1 argument for a second tier feature. Although it will lose the argument, it virtually guarantees a priority 2 ranking.

Priority 3 is the priority assigned to all feature requests that will never, ever see the light of day. These rarely even make it to the schedule.

Of course, when the super important enterprise-security feature is requested by a zillion dollar company, it becomes a priority 0 (zero) bug. If anything more important comes up, (I swear I have seen this happen) it becomes a priority -1 (negative 1) bug. I swear I've seen this mentioned in Dilbert, but I saw it happen first hand.

I wish this was the paragraph where I tell you that I'm exaggerating. It's not. I'm sure many teams do much better than this. I wouldn't be surprised if other teams were worse. Imagine the appropriate disclaimer about opinions and observations here.

Another issue that comes up on larger products is that features are prioritized per-team. This becomes a problem with team A's pri 2 features are more strategically important than some of Team B's pri 1 features. I guess if you have teams that can only do one type of feature you're stuck with this, but I think that ideally, features would be done in priority order across the entire team.

One think I love about Scrum (when it's done right) is that the backlog is re-prioritized for every sprint. This ensures that the latest information is evaluated frequently and consistently to make sure that work focuses on the most important features. Scrum, of course, sucks for larger projects, so prioritization across an entire project needs a "Scrum of Scrums", or some other more sophisticated project management to make sure the right issues are being addressed.

The thing in common with the method described above for feature prioritization, and for my previous post on bug  priorities is that the priority process is somewhat subjective. Sure, smart, knowledgeable people are making the choices, but often those decisions are made with too much weight on emotion, and not enough on ROI.

I have some ideas on how to do this part better, but I'm afraid that I'll have to save the conclusion for another post.

Skip to main content