Like most of Agile, task priorities are an opinion-driven and highly debatable subject.

Do we go low-high and have only two, as medium is meaningless in most contexts?

Do we have high-medium-low, because three is the magic number and there are tasks that are neither high nor low.

Most Agile setups default to the defaults of P1 to P5, with P1 meaning urgent and P5 generally having the lowly and unspoken definition of ‘never if at all’.

This doesn’t help. All the tasks that are business critical are P1 otherwise the biz folk wouldn’t have created them in the first place. All the bugs are P1 because the testers set them as this when they were added, because they block other testing. All the tech debt is critical because the tech lead wants a pure codebase. Ok, these example are exaggerated but common in many cases.

What we need is a scale to help force changes in priorities, so I present to you…

The Randonomicon Sliding Scale of Agile Task Priorities! The RSSOATP for short.

Here’s how it works. Half of the tasks are P5 Low, no more and no less. You can round up or down but be consistent.

Half of the remaining 50% of tasks are P4 medium-rare.

And also half of the remaining 50% of tasks are P3 middle-of-the-road medium mediocre activities.

Again, half the remaining tasks to set the P2 medium-high.

Finally, what’s left is the P1 Urgent work.

You can never have less than twice as many P2 as there are P1, and so on for the rest of the tasks. This creates a pyramid format.

In numbers as percentages you end up with

  • p1 3%
  • p2 6%
  • p3 13%
  • p4 25%
  • p5 50%
  • total 97%

Yes, it adds up to 97% because of rounding. There’s no need to be completely precise here, be flexible and pragmatic.

So if you have 200 tasks in your backlog, on planning day you’d expect 6 to be P1, a dozen of P2, maybe 25-ish as P3 and so on.