Agile Australia 2011 Series - Prioritisation
Prioritise everything you do. Accept that there’s not going to be enough time to do everything you want to do. Simple.
Think about the prioritisation choices you have made today in selecting what you worked on, what you logged onto, what you decided to read. In my job and in my personal life I prioritise all the time in order to get through the work and living I need to get done. I prioritise my children’s food and ask myself if they have eaten healthily enough to give them a treat after dinner, I think about what family and friends I want to catch up with on the weekend and I organise my priorities to include exercise. It’s this very human characteristic of making fast choices of priority without the complete picture of information to hand, that makes Agile such a comfortable and easy fit for people when it comes to building software.
When we apply prioritisation in agile projects we need to be ruthless; time is money and we can’t do everything. If we needed to complete everything in our busy days as humans we never sleep, so we start with the things that return the most value back to us.
In a similar way prioritising the scope of a project in order of most important first will return us a better value back to us, and an agile approach gives us the appealing ability to commence the realisation of that benefit earlier.
On projects, banish the ‘it’s all must have’ conversation. Really, I mean tackle that conversation early and often. This is a great way of getting customer & stakeholder engagement on your projects as they will soon see how important it is to be in the room when prioritisation calls are happening.
I believe it’s also important to be very disciplined about the ‘So that’...part of the story. In the familiar “As an X, I want Y so that Z” syntax, “So that Z” represents the value of what you are delivering. If as a collective group we are seeing everything as ‘Must Have’ the following questions can be very helpful
- Which business objective does this story directly add to? What would be impacted?
- Does it make any money for our organisation?
- Can we go live without this?
Clarify your thinking around these questions; as a group as it’s easy to have empathy with the situation of the customer, when the right thing to do is make better decisions for our organisations. It’s easy to accept a baseline of MUSTS that isn’t real. I encourage you to challenge that behaviour often.
Outside of project work, I have found quadrants very effective in helping to prioritise what we need to do next at a department level. There’s something comforting about listing your idea for change even if it never makes it to the table for consideration. Quadrants are great for giving us a clear idea of where we can start – the magic “sweet spot” quadrant of high value/ low effort, and quadrants are also good for helping us feel better about not starting certain things in the nasty high effort/ low value quadrant.
Prioritisation is not exclusively a practice or principle of Agile – you don’t need to be an ‘agile IT department’ to be making prioritisation choices, but agile practices and techniques will make aggressive prioritisation much easier. A word of caution: if you are not an ‘agile IT department’ and prioritisation is never coming up as a topic in your organisation, you are building too much into your software.