RallyDev.com
Fri 5 Jun 2009
I Don’t Like MoSCoW
The MoSCoW technique for backlog prioritization has its flaws
It’s OK Sergey and Boris. I’m not referring to the capital city of your homeland with its rich history of classical music, literature and sporting heroes.
Instead I’m referring to the technique that the DSDM consortium recommends for prioritizing backlog items – the acronym MoSCoW, which stands for:
- Must Haves
- Should Haves
- Could Haves
- Won’t Have (this time around)
There are a couple of problems with this technique, and in my classes my students spot them right away.
- The customer always thinks everything is important, and therefore the distribution of the backlog items is hopelessly skewed towards the Must Haves.
- Let’s say we are planning an iteration. We have only room left to take on one more backlog item, but we have two Must Haves. Which one gets planned into the iteration? Of course we should ask the customer, but what if they aren’t there?
Many customers think that promoting backlog items to Must Haves is exercising better control over delivery, but in fact it is not. A customer who cannot differentiate between the importance of backlog items is ceding control to the delivery team. Work has to be sequenced, and if the customer will not choose then the team will.
A better technique is to rank backlog items such that no two items have the same priority. In this instance, it is very clear the preferred order of delivery.
I have to admit I’ve never understood the point of Won’t Have.
I think that MoSCoW should be used as a first-level sorter, followed by the individual sorting. If you can get them to stop thinking everything is #1 and only 1/4 of the things are #1 (all the musts), you’ve made some progress, don’t you think? Then they can concentrate on making sure they’re clearest on what they mean by the stories in the must category so that we spend our time estimating those instead of things that might wind up with Ws.
That is, I see MoSCoW sorting as useful _before_ estimation.
In your situation #2, I’d say you either wait (because you had their commitment to be a part of the team, right? :) ) or you pick the one that fits the theme or has technical advantages. He/she is giving the team some autonomy there, right?
I’ve used a MoSCoW-like approach for years before any agile involvement as a “pre-sort” technique (as John Martin suggests) when faced with a lot of requirements. Then, the 1-n sorting goes on within each category.
I, too, have always found the “Won’t Have” category to not be very useful. I know it’s supposed to be where things go that, after reflection, won’t be part of the current delivery plans. But the “Could Have” category is close in meaning as it represents things that can be left out (of the current increment). Of course, the Could Have description refers to “the current increment” while the Won’t Have refers to “the current delivery” which is, presumably, made up of numerous increments.
But it is how the categories get used and how granular the approach is in making distinctions between items that would be the key for determining what goes into a specific iteration. At that level, buckets, with otherwise unordered contents, can produce the issues the people in classes note.
Thanks for the article Ken. You really bring up some good information about MoSCOW abuse.
My first exposure to Agile was through DSDM. So, I have to admit I have something of a pre-disposed likeness for MoSCoW. It was a great way to do the pre-sorting mentioned above. I think of it as a garage sale, where there is agreement about how many items can be MUST HAVEs. And, I use the “W” sort of like the bottom of a Product Backlog. The product owner “WOULD” get them if the backlog weren’t so big and they didn’t have so many higher priority items and didn’t keep adding more.
The idea of using them in a silent grouping for initial buckets can help a team stand back and see the truth of initial impressions about the “MUST HAVES”. Wow! We have a lot. Are you now prepared to rank them, product owner? Do you really want us to now size allllll of these before we start to give you commitments?? Having that bucket visual can be a real eye-opener. And it can be a nice way to jumpstart the ranking for those cantankerous product owners who first refuse to.
Anyway, just some ideas about how to NOT let MoSCoW abuse continue! Thanks for bringing this up. The only way to address a problem is to first admit you have one. I think that is definitely true about MoSCoW (ab)use :- )
Jean
I agree with all the excellent comments here. I use MoSCoW during the first sweep prioritisation so we have a high-level understanding of what’s important to the client – and I have to admit that I’ve hardly seen any features in the “Won’t Have” bucket!
But then I use this output and drill down into more detailed analysis with the client, so that they score each feature based on the benefit to the business of building it and the impact of leaving it out. Then I get the techies involved to get some stats on how easy or difficult it will be to develop, whether they can re-use previous code or it’s cutting-edge technology. We also weight some of the features depending on critical (business) importance. This normally provides a more detailed prioritistion for the Product Backlog; but then we sit down with the client so they can apply some business judgement to the scoring. It doesn’t work every time but it helps us kick off the first Sprint and gets the client thinking about what “really” is their priority.
Thanks for all the comments. I’m encouraged to hear that everyone responding has a pragmatic approach to the technique.
Almost every email I got on an Atern roadshow mentions MoSCoW prioritisation and I was curious to find out how integral it is to DSDM.