Introduction
An essential part of an agile way of working is the ability to prioritize. Prioritization enables an agile team to protect quality and to hit a deadline.
However, there is more than one way to prioritize and one of the most powerful techniques is only used by a small percentage of the agile community. The prioritization approach in question is the MoSCoW technique.
Here at agileKRC, we have been helping organizations achieve greater agility and helping their agile transformation for many years now. We teach our clients how to use MoSCoW to help them get more from their project management and product delivery.
The MoSCoW technique is a very powerful agile prioritization tool that helps you deliver what really matters first, but at the same time protecting quality. If you want to understand how it really works and how to identify the ‘eureka’ moment when everyone gets it, then view this video. It’s a few years old now, but everything I talked about in the webinar still applies today.
For people seeking agile certification, MoSCoW prioritisation is included in both our Agile Project Management courses and PRINCE2 Agile courses.
Video
In this video, Keith Richards, the Founder of agileKRC and Lead Author and Chief Examiner for Agile Project Management (AgilePM) and DSDM Atern, and Lead Author of PRINCE2 Agile explains why you need to prioritize on agile projects and how to use the MoSCoW technique effectively on your projects.
This video is a recording of a webinar which Keith looks at prioritization techniques in general, but the MoSCoW method in particular, and covers:
- The basics about prioritization.
- MoSCoW method and the 80:20 rule.
- Prioritization at different levels.
- Practical tips.
- The 60:20:20 ‘rule of thumb’.
- Advanced prioritization.
Download PDFs
Unanswered questions
At the end of the video recording there were quite a few questions asked by attendees that I didn’t get the chance to answer in the webinar. So, we have included the questions and answers here.
Q1/ The 60:20:20 rule is nice, but bloat sometimes means finding out something is just bigger than you thought (e.g. technical issues emerge). How do you deal with having to adjust scope when your 60% turns out to be 101% of time?
This is a fact of life and is why having features that you can drop out acts as a contingency for the project. A well-run and well scoped project should be able to handle this quite normally but the example you are giving shows that the project was badly estimated. It appears that the project needed to use nearly twice as much time as had been intended. The use of timeboxing and realising that there was so much the de-scoping going on would force you to ‘fail fast’ … and remember failing fast is good if you are going to fail.
Q2/ Could you outline the perfect project for Agile, and the perfect project for PRINCE2?
I would be reluctant to answer this question because I do not believe you should think this way. PRINCE2 is an approach to project management and agile is a very broad term that encompasses (primarily) a series of delivery techniques, but also project management. I believe the question you should be asking is how much agile do I use on this project? Unless of course it is not a project and then you would treat it simply as business as usual (BAU).
Q3/ Are there any free MoSCoW tools that you would like to recommend using on projects?
The simplest free tool you can use is a spreadsheet application. Using a low-tech solution such as a whiteboard with index cards or post-it notes is also good. For more complicated situations where you may need to satisfy audit requirements then you might try looking at particular tools. My general advice regarding tools though, is to see what you have already got and do not ever let tools drive your process.
Q4/ At the start of the project should the business/BA/PM agree the definitions of each MoSCoW priority – i.e. Must = does it deliver the business case etc?
The simplest answer to this question is yes. Everyone needs to know what is meant by a Must, Should and Could. Linking it to the business case can be quite complicated so go carefully here. Linking each requirement to some formal business value is quite tricky but has a lot of advantages going forward. If in doubt my advice is to do what the streetwise MoSCoW guide advises and that is ‘keep it simple’.
Q5/ How do you handle “Shoulds” becoming ‘Musts’ as the stakeholders change their minds?
Again, this is a fact of life and you should embrace change because it is going to happen. I would suggest you need to look at why a Should has become a Must as this may mean the project objective is changing which could be a cause concern, or the moscowing was not done correctly in the first place. Priorities do change but finding new Musts is something that can be quite painful. However, remember you do have contingency in the Shoulds and Coulds to cater for this
Q6/ I once saw a demo of a product called DOORS which used a method of comparing requirements to prioritise (e.g. is #55 more important than #33) – does not strictly define the Musts but would you see any benefit in this technique?
I like this question because I get this question quite often. There is some merit in comparing requirements but surprisingly from my experience not that much. Again, keep it simple, a Must is a Must, a Should is a Should and a Could is a Could. Further to this point it is worth noting that you cannot have a Must that is more important than another Must.
Q7/ I’m about to introduce Agile into an Ad agency that’s never heard of it before… as Kanban. Any advice as to where to start?
Crikey! That is a very big question. In very simple terms you need to start with understanding what you are trying to achieve with agile because you need to be aware it is a means to an end and not an end in itself.
Q8/ In software projects on average, what % of features are used? Is the answer useful to tell clients?
I think this is a very interesting figure to give to your clients because the general feeling from some research which you will find on the Internet is that in the region of 25% of features are not used at all and a further 25% are barely used. Irrespective of the exact figures this does show that when you are looking for contingency on a project – the scope is the best place to go as opposed to time, money or compromising on quality.
Q9/ What are your thoughts on using value to get to MoSCoW? For example, SAFe advocates WSJF (weighted, shortest, job first). Or Business Value Model? Or ROI? Should these “value” metrics be part of prioritization?
I believe that this is a good idea although it is quite advanced. I would suggest to anyone that they learn to walk first before they run. Generally speaking return on investment (ROI) is a good indicator to value. Take care with concepts such as WSJF because they may not be appropriate in a project context whereas it is fine for BAU.
Q10/ What tools similar to Atlassian JIRA do you know which supports MoSCoW priorities handling out of the box?
I hope the earlier answer addresses this one.
Where do you stand on relative priorities for Shoulds? e.g. It’s not a Must but I really want it more than the other Shoulds.
Take a look at my response to an earlier question similar to this but specifically I find that the customer or business engaged on a project automatically handles these relative priorities and in the real world you rarely if ever need to do any relative prioritisation in advance.
Q11/ You talk about MOSCOW against time, but can’t it also be applied against budget where budget is more of a limitation than time?
Yes you can do this and some people refer to a concept called ‘costboxing’. However, one of the strongest weapons in the armoury of agile is to create immovable deadlines that focus everybody’s minds and delivers a working cadence. There is also a very close relationship between time and money hence the expression ‘time is money’.
Q12/ While you mention (MoSCoW) dependencies and grouping of these, it shouldn’t be confused with product user stories which follow INVEST in that a user story is not dependent on another – yes?
I agree that these two groupings or lack of groupings i.e. independence are not the same thing. User stories should be independent of each other so that they can be worked on separately. But the functional groupings that I mentioned during the webinar relates to bunches of user stories that relate to the same thing such as the ordering process or the payment process. Sometimes these are badged as ‘epics’ but be careful not to oversimplify this concept.
Q13/ How frequently do you recommend to review the priorities/re-prioritization, in particular in the situation like you have 300 requirements in a project/release backlog?
I may have answered this one during the webinar. Prioritization is something that is a continuous process. It happens on a daily basis as the understanding of the project grows and the requirements become clearer and therefore change. I would not prescribe a specific time interval other than the notion that in effect you are doing it all the time.
Q14/ If you have 60% musts at the project level does this mean that the customer needs to agree to potentially 40% of the features/benefits not being delivered?
Yes that is absolutely correct. However, if they did lose 35% of their project they think they might be a little disappointed all other things being equal. It is reasonable under normal situations for a customer to expect to receive all of the Musts all of the Shoulds and a fair amount of the Coulds.
Infographic
