The common component in most software development agile practises is the backlog – a list of user stories, often written on cards, that represent a feature or a piece of work that needs to be completed by a member of the development team.
This backlog of work needs to be prioritised – and I have seen different people do this in different ways.
I’ve seen these items prioritised individually in excel by a single individual, where many different factors have been scored and a calculation applied to give a final score where weightings have been applied. This took a lot of time and a lot of toing and froing – all the while the development team were working on lower value items. Made no sense to me.
This list is then ordered largest value to smallest, resulting in one person’s opinion on what his list should be. This did not take into account any development team member’s experience, as well as any other teams that may be impacted by the work.
Any new items would need to be scored in this fashion, debated extensively and then slotted in to the backlog.
As far as I am concerned, this is not the way to prioritise work – especially in an agile environment.
A big part of agile is collaboration, responding to change and having working software at the end of each release. Why not apply these five principles to prioritisation.
Get everyone together
If someone is involved or impacted by the functionality being discussed, get them involved in the prioritisation – within reason obviously. At least have each department represented and ensure that there is one mediator and someone who can make a final decision if there is a disagreement.
Understand the goals
Set out at the start what the strategy is for your product and set out the objectives. Each user story or card needs to constantly compared to these objectives and ranked according to how far it goes to achieve these goals.
Relative priority
Keep things simple. Select a starting point buy placing a card in the middle of a table. Discuss this card and ensure that all involved understands exactly what this card represents and how it helps to achieve your product’s strategy and objectives.
Select the next card, discuss what it is and explore it’s benefits, risks, amount of dev work etc and then place it above the card if it is more important or below this card if it is less important.
Keep doing this with each card until you have a fully prioritised backlog. If its a big backlog, then you may need to split this into a couple of sessions.
Be flexible
Through discussion, you may find that items are no longer required or require more definition or to be defined. You can do this in the meeting itself or separately.
Future proof
Once finished, when new items come up, they can be easily prioritised as all members of the team understands the backlog and how it is made up. You place the new feature in the backlog relative to everything else.
In my experience, this is by far the best way to prioritise work. Having items prioritised relatively compared to other work get’s the business to understand that they cannot have everything all at once and that a decision has to be made as to which is more important than the other. You do not have a spreadsheet that gets ignored with multiple items with the same value.
Items can be redefined as you go and the team as a whole has been included and feel valued. The whole team has a voice. This leads to highly motivated team who have bought into the product and what is trying to be achieved.
