The product backlog is meant to be an ordered list of items. Thus, the topmost item is the highest priority, then the next, and so on.
This forces you to choose a specific item to work on first.
If you have a field called “Priority” with values P1, P2, P3, P4, it means you’ll only ever work on the P1s – maybe some of the P2s. For anything below that, why is it on the backlog? Will you ever get to it?
But let’s say you have a project to deliver functionality across 30 stories. All the stories are of equal priority as they form part of the project MVP.
How do you prioritise those stories?
First, look for risks: areas where there is uncertainty, and that could trip you up if they are looked at too late. Picking these up sooner gets them out of the way and helps increase confidence in completing the remainder of the stories.
Next, look for dependencies: anything that can’t be started before other stories are completed. The priority can then be to work on stories that will allow others to be picked up.
Finally, look out for any big stories that may not fit into a single sprint. These shouldn’t be left until the end in case they are not completed in time. Splitting them up may be possible, but if not, starting them early gives a better chance of spotting issues sooner.
Even when everything is a priority, it’s still possible to prioritise within your top priority items.