Project Management - Using MoSCOWX
Last year I went to a talk during the Tri-agile conference about Business Analysis. I have been in an Agile environment for a number of years, but we didn’t use MoSCoW to rank features. Intriguing but I didn’t think about it much until my annual Evernote review.
Traditionally MoSCoW stands for:
There are a bunch of variations for the last W won’t, wish, etc. Frequently I see an X to stand for exclude since some features do not deserve to live. On my next project I am going to use a modified version that overcomes some criticism of the original MoSCoW.
In an iterative process, this emphasizes optimization of the product before wish features start to get tacked on. I’ll leave the definition of optimization broad. It could be refactoring code, speed improvements, UX improvements, workflow improvements, user journey tweaks, or security upgrades. Think of the O as the devs getting a spot in the requirements ranking.
We have all used software that has an exceptional amount of features but fails in one of the above areas so badly it is unusable. In less extreme cases, an early round of optimization would reduce the pain some projects experience to get to a beta release.
My thinking is that having Optimization on the board when meeting with business stakeholders they will have a focus on a higher quality product rather than just features. This may backfire with more ‘wish’ features being pushed into the could category.