15

I am using a project management system that forces me to define feature requests as either High, Medium or Low priority. Has anyone got a good set of definitions that clarifies what those priorities should mean?

I think it would focus our minds better if we had specific definitions of what those priority levels actually mean.

Improve this question
4
  • Is this question more about how to analyze a feature such that it results in a priority level score or are you really asking about a definition of each level?
    – David Espina
    Commented Mar 28, 2014 at 12:27
  • @David Espina - Seeking a definition of each level that can assist in a good first pass at prioritization. I would consider High/Medium/Low method to be a quickndirty, high-level 1st attempt at prioritization
    – gbh
    Commented Mar 28, 2014 at 14:30
  • 1
    Gotcha and that's what I thought. Todd's write-up below (CodeGnome) is spot on. Go ahead and click on that check mark...:)
    – David Espina
    Commented Mar 28, 2014 at 15:16
  • Hey Gary, one of the answerers was wondering what your role in the company is? (He can't post comments yet, so I'm posting on his behalf)
    – jmort253
    Commented Apr 3, 2014 at 3:19

3 Answers 3

Reset to default
15

Definitions Must Be Localized

I am using a project management system that forces me to define feature requests as either High, Medium or Low priority. Has anyone got a good set of definitions that clarifies what those priorities should mean?

They mean whatever your organization wants them to mean. How any given organization prioritizes features or tasks is based on a variety of factors, including (but not limited to):

  • Urgency
  • Value
  • Cost
  • Timing
  • ROI (Return on Investment)
  • Marketing or public relations concerns
  • "Squeaky wheel" customers
  • Opportunity costs

In other words, your organization must develop a scoring system or a set of sliders that allow you to filter and prioritize features in a way that makes sense for your specific business.

Coarse-Grained Priority Buckets Suck

Even with the foregoing in mind, large priority buckets are a terrible idea. There's a reason that frameworks like Scrum require ordinal prioritization. Quite simply, if something is "most important," by definition everything else is subordinate to that objective.

If you sort into coarse-grained priority buckets, you end up with situations where you might have 37 "high priority" features. Not everything can be the top priority simultaneously, although it's common Bad Management Practice™ to think so.

Unless you have secondary filters for each of your priority buckets, your project is likely to multitask itself to death. Even if you don't, will you:

  • Work through buckets on a first-in, first-out basis?
  • Work on the low-hanging (and potentially lower-value) fruit first?
  • Will you work on the hardest (and potentially schedule-destroying) stuff first?

In addition, unless you put a lid on your high-priority bucket you will never get to the medium or low priority stuff. Ever.

A More Sequential Approach

Generally, coarse-grained buckets are acceptable as a first pass, but you should strongly consider a second pass with some kind of ordinal prioritization queue. Mountain Goat Software has some nice web-based tools for helping teams use Theme Screening, Theme Scoring, Relative Weighting, and Project Success Sliders to help the stakeholders give truly sequential priorities to features.

Always remember CodeGnome's First Law of Prioritization:

If everything is a "top priority" on your project, run (do not walk!) to the nearest exit.

In my experience, undifferentiated "top priority" queues are generally the main source of project failures and death marches. Don't be a statistic.

Improve this answer
3
  • 1
    Nice answer. +1
    – David Espina
    Commented Mar 28, 2014 at 13:36
  • 3
    Curses - this is the substance of what I was going to write, but better written. (although I was going to start with "What are some good definitions of a good girlfriend...." The value isn't in the categorization, it is in the process of defining the categories. Kind of a general principle of PM.
    – MCW
    Commented Mar 28, 2014 at 14:04
  • Speaking of 27 high-priority tasks, there's a great Back to Work episode on the topic of priorities.
    – Adam Wuerl
    Commented Apr 2, 2014 at 4:28
1

Priorities are defined based on the needs of product owners. It is decided based on factors like Importance, Urgency, Effort

  • If it is a critical feature which the product owners wants immediately or a feature that has impact on creation on other features and/or which doesn't relatively take time(depending on sprint duration) that can be named as High
  • The feature which is relatively important but not as important as High is named as Normal
  • The feature which is not required immediately or which doesn't have any impact of basic functionality of app can be named as Low priority.

To know more about deciding which feature is to be given which priority please check the following link:

http://www.wikihow.com/Prioritize

Improve this answer
1

If you're using scrum, ask your product owner. If you have a manager or CEO (or whatever) above you ask them.

Your definition of high priority is always different than the product owners' or CEO's high priority.

If they don't have a clue what you're talking about, create simple to understand example for them.

So, the main server goes down, do you want me to fix that within 2 or 8 or 24 hours?

Improve this answer
1
  • Hey Theo, I edited out the question and will add it as a comment to the question so the asker can edit if needed. Please avoid putting questions in the answers section. Once you earn 50 rep, you'll be able to add your own comments. Also, thanks for participating!
    – jmort253
    Commented Apr 3, 2014 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.