Prioritising versus ordering: what is the difference and why does it matter?
30 March 2016
Deciding on the most important thing to work on at any given time is not an easy task for a project team, but it is one of the most important decisions that needs to be made, many times over, from the start of a project through to its end.
A few years ago I was tasked with being the Scrum Master on a project that had a huge amount to get through in a short period of time.
There were many perplexing elements to the project, but one of the most perplexing was that the team had prepared around 400 user stories, all written to varying degrees of detail. I would have hoped for scant detail on each, followed by a prioritisation exercise and a couple of sessions to expand on the most valuable stories.
However, we were asked to flesh out, estimate and order all 400 before the first sprint.
We spent three agonising days refining the backlog. I suspected most of this work would be of little use as many things would change as soon as the first sprint was underway.
I also attempted to run a prioritisation exercise, and I learned pretty quickly that the word ‘prioritisation’ was frowned upon, and the term ‘ordering’ was preferred.
But what’s the difference?
Prioritising, in the Agile world, focuses on identifying the business value of each story, doing the most valuable work first, delivering quickly to get feedback and then reprioritising the remaining work based on what we’ve learned.
Ordering is a type of prioritisation, but it’s based on an assumption that we already know everything we need to know about our project. In this case, ordering meant that every story was of equal value because every story absolutely needed to be completed for the project to be considered a success.
I have never come across a project that couldn’t be broken down and prioritised by value. It isn’t always easy, but it is always necessary. Without truly prioritising, the team runs the risk of building features that no one will actually benefit from, and working without any useful feedback on what was delivered earlier in the project.
Assuming everything is equally as valuable is sure to result in both time and budget running out before we deliver the most important benefits to the user.
Have you ever faced a prioritisation challenge? Has someone in your team, or maybe at executive level, advocated for their own pet part of a project over what is really valuable to the customer? Have you disagreed with your colleagues about what should be done first?
Be prepared to make those hard (but ultimately satisfying) decisions, because prioritisation drives your team’s performance and ultimately ensures you deliver value to your customer.
To find out more about prioritisation, come along to our Agile Professional Foundation two-day course with certification.
Find how to prioritise user stories during a project kick-off.
Read about our experiments creating user stories with story mapping and ‘buy a feature’ prioritisation.
View our post covering a range of Prioritisation tools and tips for Agile projects.
Get tools to measure and improve how well you prioritise so you can reduce software development risk with Agile prioritisation.