Head to your project Trello board, or JIRA, or whatever tool you happen to be using, and look at your backlog. How many of those tasks are in each of the highest, high, medium, low or lowest priority levels?
If it is more than 5 in each priority level, you have got a problem. Here’s why…
First, having, say, 20 tasks in the highest priority level is of little use. A software team will be unable to work on 20 tasks in a single sprint (or even two sprints), so having 20 highest-priority tasks simply dilutes the authoritative meaning of the priority levels.
Second, it does not force the project or product manager to make hard decisions between priorities. It is easy to mark everything as a high priority; less easy to make a call. But, making these hard decisions is fundamental to a well-organized software project.
Third, it makes it difficult to rationalize about tasks during discussions amongst the team. Since we humans can only keep 7 ± 2 items in working memory, it becomes difficult to even plan a sprint once the number of tasks under consideration becomes larger. Many teams will do some form of ‘prioritizing their priorities’ – this is a bad idea for the two reasons above: it dilutes authority and it avoids hard decisions.
So, if there is one thing you can do to better the management of your software project, it is this: limit your priorities. Implement a rule that each priority level has no more than 5 tasks within it.
If you introduce a new task that is highest priority level, you must delegate a task to the next ‘high’ level and so on until you have 5 tasks within each level. This forces you to make the hard decisions, maintains the authority and utility of priorities and will make communication about priorities a whole lot easier within the team.