The 3 Levels of Feature Prioritization

I use a three point scale for prioritizing web application feature development at Code and Effect. Each feature is given a number that represents a priority:

  • 1 - NEED to have
  • 2 - NICE to have
  • 3 - NOPE

1 Priority - NEED to have

  • This feature must be developed because it has clear and obvious business value.
  • Is part of the minimum viable product (MVP) for a project.
  • Without this feature you might as well not even do the project.

2 Priority - NICE to have

  • Might have value, or maybe it needs something else first, but everyone would be able to make do without this feature.
  • Not part of a minimum viable product.
  • Often these are the features that make it into the first or second major update.
  • The 2 priority is where pet features go to die without anyone feeling really bad about it :)

3 Priority - NOPE

  • These are long term features, or perhaps even never features.
  • Not part of an MVP app or feature.

Why a three point scale?

  • It makes a clear decision: only “1 Priority - Need to have" features are actioned. Ignore everything else.
  • It's simple to explain and easy to understand, even if the feature to be implemented is technical.
  • Priority scales greater than 3 simply cause confusion. What am I supposed to do with a priority 4 out of 5?

What are some tactics and processes to prioritize?

Note: these will link to posts when written. If you want to be emailed when they’re published, subscribe.

  1. Priority poker
  2. Feature sheet prioritizing
  3. Expert recommendations

Should I re-prioritize within each priority level?

No. Prioritizing within each level will create more than 3 levels of priority! The goal of prioritization is to define what needs to be actioned and what can be ignored, and prioritizing within won’t change that.

Ordering features within a priority to plan a development schedule is OK, just don’t try to look at it as prioritization.

When should I prioritize?

It’s easy to get stuck going over the feature list again and again, sorting through priorities. I try to only prioritize features:

  1. When the feature is first discussed (e.g. as part of Discover and Plan).
  2. When the feature has a cost attached to it.
  3. When there are no more priority 1 features left to implement.
  4. When you have a significant change in certainty or risk on the project.

How many features of each priority should I try to have?

As a rule I try to immediately prioritize 1/3 of all features into a ‘3’ priority, and then do it again with the remaining features. I say this out loud with “cut by a third, then cut by a third”. It doesn’t matter if the remaining items are 1 or 2 priorities, what’s important is to eliminate as many features as possible by prioritizing them a 3.

For example when starting with 100 features: prioritize 33 as ‘NOPE’ (this is usually easy) and then from the remaining 66 try and prioritize another 25 as ‘NOPE’ (this is harder). In the end you should have 40-50 features of the original 100, most of which are 1 priority.