A question I’m often asked is what is the best method to prioritise an agile backlog.
Whilst I’m always keen to avoid a ‘best solution’ – Agile should stay away from absolutes and adopt the best solution to meet their needs at the time – my personal favourite is MoSCoW.
Why MoSCoW? Well it just seems to fit so well to Agile.
The “Must” part of MosCoW are the core reason you are doing the work, if the outcome doesn’t achieve these then there is no point doing the work in the first place.
You should be aiming to get the “Must” to the absolute minimum possible. As a good rule of thumb if over 20% of the requirements you have are “Must” then you have too much in there.
A good example of “Must” items are regulatory things like “must be GDPR compliant” or things that are vital to the tool to work “must be able to take at least one form of payment’
Plugging this into Agile, these “Must” items therefore are your MVP, the bare minimum that must be achieved before the tool can be of any use.
“Should” items therefore are things that you definitely want to achieve before you call an end to the project, but don’t nessarilly need to be there from day one.
“Should” will probably be your largest area of requirements, and you should expect anything up to 70% of requested features to be “Should”. As a result of this it is often the case that tickets find their way into should that probably shouldn’t be there, and they either are vital and should be “Must” items, or they are actually just nice to have add ins and should be “Could”.
As a general rule your “Should” items should fall into two types:
1) Items that have become the industry standard to such a degree that not including them would put us behind the opposition (assuming these didn’t make it to “Must”)
2) Items that are a significant improvement on what is in the market at the moment such that they would give us an obvious market advantage (assuming these didn’t make it to “Must”)
Plugging this into Agile, your “Should” items would be the highest priority items that you would work one AFTER you have delivered your MVP.
“Could” is always my favourite area, as when we work in IT anything could do just about anything!
The goal with “Could” is to list items that are not needed for the MVP, and wouldn’t give your product a market advantage – but instead to list things with a less tangible benefit that you want for your product.
“Could” again can be a large part of your backlog, and a list of “Could” items up to 50% of your tickets is not uncommon. I will say that if you have over 50% of backlog items marked as “Could” then you are probably trying to make the tool do too many things and should look to spin up a different project to cover some of these “Could” items after you have completed the current project.
Often people keep almost any requirement not in “Must” or “Should” into the “Could” column, but that is a mistake. As the Product Owner it is your role to be the gatekeeper for the product and ensure that it is staying on track with the product goal – including every idea that a user comes up with will prevent you doing your job.
Plugging all this into Agile then, your “Could” items are low priority backlog items, to be fit in as and when scope in the larger project allows. “Could” items are the first set of items that you can close the project as completed without having delivered.
The “Won’t” pile can massively vary depending on your organisation. Some organisations are very focused on project aims and will have very few “Won’t” items, whilst others have more of a free for all culture and everytime an item of work started anyone and everyone can suggest anything regardless of if it makes sense to the aim of the project or not.
Both of these methods work fine, you just need to be aware of the organisation culture so you can plan the size of the “Won’t” pile accordingly.
“Won’t”, as the name suggests, are items you will not be doing regardless of how long the project runs. There could be many reasons for this but it usually falls into one of the following:
1) The cost to achieve it would be too expensive
2) The effort to achieve it would be too difficult/technically it isn’t possible with your current staff/tools.
3) The idea is completely out of left field and takes the product into areas that are not part of the product vision.
Plugging into Agile your “Won’t” pile would never even make it to your board, however it is still important to document these and manage the stakeholders so that they are aware they are not getting this, and the reasons why. It is also important to document these because it is possible they are some good ideas in here. You should regularly review old “Won’t” requirements as it is entirely possible that there are some excellent ideas in there that could be projects on their own. “Won’t” does not mean it is a bad idea – just that it was a bad idea for the Project/Product it was suggested for.
I hope you’ve found this useful – as I said at the start I’m not saying that MoSCoW is the only way to prioritise a backlog, but it is my favourite and seems to me to fit best into Agile methodologies.