Project management priority score for ranking goals, tasks, issues, etc.
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
README.md
README.png

README.md

SixArm.com → Project management →
Priority score

Priority

Priority score is a simple way to rank items, such as goals, tasks, issues, etc. This page explains the task priority score that our teams use.

  • Priority 0 = Emergency
  • Priority 1 = Must have
  • Priority 2 = Should have
  • Priority 3 = Could have
  • Priority 4 = Would have

You can freely customize this task priority score for your own needs. We welcome feedback and also suggestions for improvement.

These are thanks to many clients and many years of experience.

Priority 0 = Emergency

  • Summary: Do this immediately, update team immediately, and work 24x7 to solution.

  • Impact: Severe business loss that is continuing and/or worsening, or the team is in failure state, etc.

  • Response time goal? Within X minutes.

  • Milestone blocker? Yes.

  • Feature examples: None, because no feature is this important.

  • Incident examples: System is down, or is corrupting data, or significant customers are entirely blocked.

Priority 1 = Must have

  • Summary: Urgent work that has very high value and very high need.

  • Impact: typically high number of users and/or high business value and/or high visibility.

  • Response time goal? Within X hours.

  • Milestone blocker? Yes.

  • Impact: Must meet its deadline, otherwise there will be significant business loss, and/or the team fails.

  • Feature examples: critical to the current delivery for it to be a success; if even one must-have requirement is not included, the delivery should be considered a failure.

  • Incident examples: typically most system crashes, or most data loss, or regressions, or a critical issues for which there is no work around yet other areas of the system are still functioning.

Priority 2 = Should have

  • Summary: Wanted for current milestone; most work should have this priority.

  • Response time goal? Within X days.

  • Milestone blocker? No.

  • Feature examples: Any typical planned feature.

  • Incident examples: A bug that has a reasonable workaround, and will be addressed in next significant update.

Priority 3 = Could have

  • Summary: Desirable but not necessary; could improve user experience or customer satisfaction; could take little development time/effort/cost. These will typically be included if time and resources permit.

  • Response time goal? Within X weeks.

  • Milestone blocker? No.

  • Feature examples: an enhancement request; a feature that could improve user experience or customer satisfaction; a feature that could take little development time/effort/cost; a "quick win".

  • Incident examples: a bug in a less-used area, or that has a workaround, or that causes insignificant business value loss.

Priority 4 = Would have

  • Summary: least-wanted and/or lowest-value and/or smallest-visibilty items for this milestone; still possible to be included in a milestone (though unlikely) and/or still possible to be included in a future milestone.

  • Response time goal? Within X months.

  • Milestone blocker? No.

  • Feature examples: an enhancement request that is minor, or for a small number of customers, or that delivers a relatively small business value.

  • Incident examples: a typo, harmless, or otherwise, that is fixable when time is available.

Notes on MoSCoW

We use the terminology of "must have", "should have", etc. which comes from a project planning technique called the MoSCoW method.

The plain English wording can be helpful getting stakeholders to understand the task priority score.

One change that we make on purpose is to use "would have", instead of what MoSCoW traditionally uses, which is "won't have". We choose to use "would have" because in our experience with stakeholders, the "would have" wording tends to be clearer that a task is still may be possible in the future, even if it's not possible right now.