MoSCoW Analysis – How and Why…

One of the most baffling issues in the world of software development is the seemingly magical way a software development project tends to grow beyond its time and cost bounds.

The following White Paper outlines a development technique that we have used with success to bound software development projects and deliver viable products at a projected time and expense budget. The technique we will discuss is known as the “MoSCoW Analysis.”

An Analogy

Relating a real-life analogy to provide a basis for the technical concepts to come should help with the MoSCoW concept. My daughter’s upcoming wedding serves as a timely analogy that many can relate.

As any practical father who is facing this financially daunting ‘wedding’ experience will do, I have to put a dollar limit on this event – I am not much for surprises after the fact. Just to show you how naïve I am, I’ll just take the easy way out and pick a number; $10,000. My wife and daughter will have the hard part; squeezing 20 years of hopes and dreams into that pitifully low sum of money. Money doesn’t grow on trees.

My wife, being the ever practical person that she is, will sit my daughter down and make a list of all of the potential wedding costs. The dress, the horse-drawn carriage, everything that they have ever heard about will go on that list, along with an estimated cost for each. Some of the wedding items will be absolutely necessary and will be at the top of the list: the dress, veil and perfect shoes. Others, like the horse-drawn carriage and Justin Timberlake for the music are dream items; they go to the bottom of the list. The “must have” items are at the top, moving towards the “won’t have” items at the bottom. Together my wife and daughter must decide how to rank and order these items. There will be lots of items on the list that will be “die-without” things and many “my-friend-had-at-her-wedding” items. This is not my problem; I’m just the money guy.

Now the fun part. Simple math allows my wife to draw a line on the list where the money runs out. Anything above the line makes the wedding; anything below will not. Wife and daughter go into high gear:

• Re-use her sister’s dress, save $3,000, and the money line moves down.
• Invite the Ohio relatives and the money line moves up.
• Switch to chicken on the buffet so we can add vegetarian fish sticks.
• Change the “open bar” to “beer and wine” and the line moves down.

As you can see, the one constant is the $10,000. It is not going to move. Everything else is liquid, constantly in motion.

Aside from the trauma of cutting some “dream wedding” items, this is pretty straightforward and easy to implement – we have a plan. I will show up, dance with my daughter and all is well.

But just when I thought it was safe to relax and wait for the wedding day, my wife starts to call service providers to lock in her cost estimates and realizes the $750 she estimated for the photographer is really $950. She also discovers that my brother can get us the wine for half-price. The magic line moves up and down on a daily basis causing a little craziness in the family.

In the end, the list was a financial miracle for me. The special day comes off perfectly. The total cost is $9,970 and the bride and groom thank me for my generosity as they wave from the taxi cab on their way to Motel 6 for the honeymoon.

I know. My analogy has no basis in reality. I’ll end up spending three times as much as I originally budgeted for. Emotion will rule and the wedding will be everything my wife and daughter ever wanted. This is OK, she’s a wonderful daughter; the carriage ride was a nice touch.

Editor’s Note: For simplicity sake I’ve skipped the Time component to this analogy. My daughter’s wedding was set for December 18^th months ago. The hall has been rented, the relatives are flying in and there is no way that this date can ‘slip’. The wedding will be over or cancelled by December 19.

If you squint just right you can draw an analogy between the wedding and your next software project. You will have a fixed budget but the project stakeholders will want far more functionality than you can possibly fit into that amount of money. The only way you get what you need is to create a feature list, prioritize the list and draw the cut-off line based on cost estimates for each feature. As the project progresses you’ll find some features took longer and cost more than expected while some were less time consuming and cost hundreds, not thousands. Features will get added and some features will grow or shrink in complexity. When you run out of money, the project will be as done. Some features will fall off the backend. If you’ve done your feature-priority job correctly you will have a viable product. In the world of software development I have found ‘done’ far more preferable to ‘perfect’. Perfect is never achievable and your boss will love the fact that the project was completed on budget.

The MoSCoW Approach

Let’s take the wedding analogy in a more structured direction. Software projects are preferably defined as a set of requirements; basic pieces of functionality that can be described in a few sentences or paragraphs. Each requirement can be placed into one of four categories. Some are Must haves; meaning the final product would not be viable if these functions were not present. The next category is the Should haves. These are functions that might be awkward if they were not present but won’t disable the product if they are missing. The Could have category includes features that really aren’t needed but would make the product a little nicer. These features could be in the product if their implementation did not affect the cost or schedule. And finally, there are features that the product Won’t have, but are good to list so they won’t be forgotten or might affect the original product architecture if the designers know these features might be included some time in the future.

With a little creative license we end up with the MoSCoW acronym: Must, Should, Could and Won’t with a few ‘o’s thrown in to help us remember.

As we develop the software product, if we work from a requirement list that is ordered using our Must, Should, Could and Won’t categories, we can make sure all the really important features (Must’s) get done first. We then complete as many of the Should’s followed by the Could’s until we run out of money or time. The important idea taken from this paragraph is the concept of developing the project from the top of the priority list down. What we don’t want to happen is to run out of money (or time) and realize the dancing bunny logo (the marketing guy’s idea) was implemented, but the Login feature was forgotten.

Like the wedding, a lot of things may happen along the way:

• A feature may get redefined, deleted or added.
• The priority list may change in order based upon some new insight.
• Features may move up or down the list.

The project will be bounded by the allocated cost and/or time. The priority list or requirement definitions can change, but as long as the Must features are implemented, we are good to go when we run out of money or time.

The MoSCoW approach is, of course, a basic framework under which a lot of hard work and planning must occur. The quality of the requirements, adherence to the prioritized features list and the abilities of the developers all impact how well this approach will perform.

Problems Along the Way

A software project is the product of a need and a vision. The individual or team that conceives the project almost always has a good view of the main-stream, visible operation of the project vision which is based on a business need. What is often lacking is an understanding of the operations that happen below the surface (e.g., databases, interactions with other systems) and the many unusual conditions that need to be addressed (e.g., incorrect data entry, power outages, duplicate data). This lack of understanding of the secondary layers of the project can be corrected by an insistence on the development of good requirements.

A more subtle problem arises when there is a belief that the project must be entirely ‘done’ before it becomes viable. If you look at almost any production software product (i.e., one already in use) you can easily find features that, in a pinch, you could live without. Taken a bit further, you can probably look at all of the features of that production product and characterize its features as those you really need (e.g., login), those you can live without (e.g., spell check) and those where you wonder why anyone went to the trouble of including them at all (e.g., bouncing logos). In hindsight (when looking at an already completed application) this is not a difficult task. In designing and building a software product we often lose sight of the fact that all features are not equal in importance and the desired product will be just as valuable if some features are not included.

Finally, the real danger many software development projects have is the unbridled enthusiasm of the clients and developers. The “Wouldn’t this be great if” or “You know what we really need” thoughts are bound to happen. The development process needs to be constantly monitored for feature creep and little additions that, even though they were outside of the requirements, just had to be added and didn’t really take up that much time anyway. We have found that a MoSCoW mentality tends to focus developers as well as clients. The urgency that a well established cut off point imposes limits unwanted creative license.

Conclusion

There’s nothing magic in the MoSCoW concept. Feature prioritization and strict requirement change control has been around for years. What the MoSCoW methodology adds is the understanding that the project will be done when the time and/or cost threshold has been reached.

What WDDinc brings to software development is the strict implementation of a MoSCoW mentality. Our agreements with our clients and our insistence with our developers target a development cycle where the project will be done at a certain point. The dependence between WDDinc and the client is such that both sides understand the need to focus on the limited resources available. WDDinc is very good at this.