Unanswered questions from Master the Art of MoSCoW Prioritisation webinar

Post Webinar Q&A
Webinar Drawing

Unanswered questions from the MoSCoW webinar 09/05/2014

Several questions were left unanswered after our recent webinar on Moscow prioritisation so please find some of them below and the answers which would have been given had there been time.

Unplanned moments

It turned out to be a very eventful webinar (as those watching it live would have realised) as we had a scenery malfunction and a slight problem with the software. I hope this did not affect your enjoyment of the webinar and in fact we are getting feedback that many of you thought it was very funny indeed.

One point that we had not considered with the webinar was the use of the hashtag #musthaves. We only found out after the webinar that this hashtag is used predominantly by women to discuss items that they would recommend to their friends to purchase such as handbags and shoes. In future we will check our hashtag before the webinar and not afterwards!

Anyway now to the questions…

60:20:20 is nice, but bloat is sometimes not feature bloat its finding out something is just bigger than you thought (eg 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 this 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 would appear 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.

Could you outline the perfect project for Agile - and the perfect project for Prince2?

I would be reluctant to answer this question because I don’t 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 BAU (business as usual).

Are there any free tools that you would like to recommend to use MoSCoW on projects? Thanks, amazing webinar.

The simplest free tool you can use is Excel or any other similar spreadsheet application. Using a low-tech solution such as a whiteboard with index cards or post-it notes is also fine. On more complicated situations where you may need to satisfy audit requirements then it might be worth looking at particular tools. My general advice regarding tools though, is to see what you’ve already got and do not ever let tools drive your process.

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’.

BTW, I am ex-Oracle and have been using Dai's technique since I first saw it; thanks Dai

Glad to hear it!

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

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.

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.

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 and you may wish to look at one of our other webinars about ‘Understanding Agile: mastering the basics’. 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.

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.

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 prioritisation?

I believe that this is a good idea although it is quite advanced and 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.

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.

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’.

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.

Been a MoSCoW practitioner since 1999 and use the Toybox technique for negotiating requirements within the timebox, anyone use this?

Sorry, I have not heard of this technique feel free to email myself or the DSDM Consortium with this information and we can take a look at it

How frequently do you recommend to do review of the priorities/reprioritization, in particular in the situation like you have 300 requirements in a project/release backlog?

I may have answered this one during the webinar but prioritisation is something that is a continuous process that 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.

Sketchnote by Stuart

Well that is all that I can answer for now. We did get one question that said ‘Hey – I am from Brazil’ so I hope you are looking forward to the World Cup! I am optimistic that England will be runners-up (in the group stages that is!).

If you want to download the Sketchnote of the webinar (a pictorial record of the webinar to help you remember it) go to the DSDM website or our own website. We would like to know what you thought of this….did you find it useful.

Until the next time!


agileKRC was independently verified as a Leader for Agile Project Management training in the Trusted Training Radar® report for Agile Project Management Training (Spring 2020).

agileKRC received the highest ratings of any Agile Project Management training provider for learner satisfaction and confidence to deliver training outcomes.

Source: https://courseconductors.com/agile


agileKRC is an Accredited Training Provider for AgilePM. Accredited by the APMG (APM Group) International.

agileKRC is an accredited partner of the Agile Business Consortium, a not-for-profit professional body for business agility.