Monitoring the customer's wish list (or the backlog of requirements) is an important part of…
We are giving up on MoSCoW. And by that I mean the prioritization approach promoted by DSDM, not the Russian city. — I had already given up on the latter many years ago. — The MoSCoW approach in software development is used by many to decide which requirements should go into which timebox. The letters stand for the following priorities:
M – MUST have this.
S – SHOULD have this if at all possible.
C – COULD have this if it does not affect anything else.
W – WON'T have this time but WOULD like in the future.
The argument for using MoSCoW over an old-fashioned numbered system, according to the DSDM evangelists, is that simple priorities like 1, 2, 3 and 4 are flawed as it results in all elements being assigned priority number 1 by the customer.
However, after having tried the MoSCoW method for about a year, the feedback I got from our consultants is this: "It doesn't work because all features are being assigned the Must Have priority. Our customers are of the opinion that everything is essential."
The problem is not much different in our support and maintenance arena. There we work with priorities named ShowStopper, High, Medium and Low. Now guess which priority our customers often assign to their issues… We could just as well use priorities named ExtremelyCrucial, IgnoreThis, IgnoreThisToo and SmellyBananas. It wouldn't make much of a difference, I'm afraid.
We already know that most ShowStopper and MustHave requirements usually turn out to be not crucial at all. But there's a big difference between knowing and telling the customer. In Moscow (the city, not the method) it is quite normal to tell others (particularly other nations): "Well boohoohoo… too bad you think you need gas, you're simply not gonna get it!" Unfortunately, the approach in our part of the world needs to be a bit more subtle.
The best solution might be to use some sort of a priority ladder, or priority queue. Customers can rearrange the requirements in the queue at any time, but as soon as the next iteration starts we take the top X items that will fit the timebox. Of course, this is very similar to the planning game exercised in XP. But with the added benefit that, of those X items we take from the queue, we still know their relative priorities.
We are going to try this idea and I will let you know someday if it worked. But for now I'm going to stay clear of Moscow for a while (both the method and the city)…