Skip to content

Latest commit

 

History

History
104 lines (54 loc) · 4 KB

README.md

File metadata and controls

104 lines (54 loc) · 4 KB
Raw

Project management priority score

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 1 = Immediate
  • Priority 2 = Must have
  • Priority 3 = Should have
  • Priority 4 = Could have
  • Priority 5 = 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 1 = Immediate

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

  • Impact: Major business opportunity and/or danger that is continuing and/or growing, with high risk, etc.

  • Response time goal? Within X minutes.

  • Milestone blocker? Yes.

  • Feature examples: mission-critical to a highly valuable customer, segment, or channel; if the requirement is not solved immediately then there is no other way to make it up.

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

Priority 2 = 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 3 = 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 4 = 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 5 = Would have

  • Summary: least-wanted/lowest-value items; unlikely to happen any time soon; defer considering until a longer term 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.