preview

MoSCoW or how to reduce 50 todos to 5.

| 2 Comments

It’s common when you have to do a lot, but time/money is not on your side. The first and obvious wish would be to squeeze it all into term/budget you’ve got. But conditions would rather be unfriendly than allow you to accomplish this complicated task.

Burger ingredients: MoSCoW view by Railsware Let’s start with a simple example. Imagine you are a student and you have to buy some food for today. You know you want ice cream and candies. It would be great to have some peanut butter and bread. And you know you need clear water and meat for dinner. But there is only ten bucks in your pocket. Ice cream costs $5, candies do $4. Meat and water are $7 and $3 respectively.

Of course, you can follow your desires and go for candies and ice cream. But this means that you won’t be able to eat today. So essential needs are water and meat. And you, reluctantly, buy water and meat. That’s life.

  Here is another example. You are moving to a new place. So you need to carry all your goods there, but all you have is a bicycle which allows you to make one attempt per day. Of course, you want to have your cosy chair and favorite painting on your new place right from the beginning. But I doubt that not having plates, spoons and pan would allow you to have a meal there. So you need to move them first.

Priorities when moving to a new place. RoR development.

All these examples describe necessity of prioritization, the thing we do every day even unconsciously. Why not to do this deliberately?

In our development process we realized such need when we faced a strong client desire to get a lot of features build in short period of time or for small fixed budget. So we looked at MoSCoW approach from this point.

MoSCoW (which stands for Must, Should, Could and Won’t/Want_to) is a method of prioritization. It shows how all the stuff that lays on the plate can be ordered and get done without applying inhuman efforts.

Let’s go back to our examples above using MoSCoW approach. Now you know that meat and water would be “musts” and all the rest would have lower priority for logical reasons (unless candies are essential for your daily living). We have “shoulds” left, which probably would be bread and butter. Finally, candies and ice-cream appear to be “coulds” or even “wont’s”. So your primary list now looks like:

Must

  • meat
  • water

Should

  • bread
  • peanut butter

Could

  • candies
  • ice cream

Remember, this prioritization works only for today under current circumstances. Tomorrow, “musts” (meat and water) will be non-actual and today’s “shoulds” will become “musts”, “coulds” will move to “shoulds” and so on. In other words, if you put something under “could” or “won’t” it does not mean it won’t be done ever. Priority changes when circumstances change.

You may think that there should be other way. In our example, it is to choose cheaper goods and buy all you have in the list without prioritizing. But in that case, you will most likely pay with quality for your unwillingness to think deeper.

This situation could be projected on IT development easily. It’s incredibly common when a client wants all he stated as requirements without paying attention to facts like budget, time and product sake. Let’s say, after client interviews all the requirements transformed into the set of features. For clarity reasons, I give a simple list of features taken from one of our products:

  • sign up
  • log in
  • password reset
  • billing system
  • list of users
  • delete account
  • time-tracking page
  • time-tracking categories
  • iOS app
  • Android app

And you say “OK, taking into consideration our current budget and deadline for beta demo, prioritization list for this phase is the following:”

Must (extremely required by the app and must be done)

  • sign up
  • log in
  • password reset
  • list of users
  • time-tracking page

Should (important features but non vital for the app functioning)

  • billing system
  • time-tracking categories
  • delete account

Could (cool to have but can be done later)

  • iOS app
  • Android app

But most likely you will hear back something like: “Wait a minute.. App without billing? What if the user wants to delete his or her account? And I want to have mobile apps. And categories seem useful to me. How can we throw all that away?”.

And this is the moment when MoSCoW should show up to explain that NOTHING will be thrown away. App won’t need billing for beta, we can add it after it goes live (like Basecamp did), so billing goes to shoulds for now. Categories and account deletion will be in the app but only after “musts” are done. Mobile apps are cool, but they can be added when the main app is working already.

Features prioritized following MoSCoW. RoR team.

I would like you not to expect from a client to prioritize features using MoSCoW on his own. A better way is to interview your client, ask and write down, ask again and write down. Then, you will be able to prioritize and try to come to an agreement with the client, with reasonable points why these are M (musts) and so on. This process most often takes few iterations until all priorities are assigned and both sides agreed to them. It’s important to show that none of the features will be thrown away and forgotten, which is amazingly diffused client reaction, especially with no prioritizing experience. All feats just were organized into a queue where place of the feature corresponds to the current feature significance for application at this phase.

We used this practice when we realized that the list of what we wanted to get done we were facing was monstrous and unmaintainable (check out Critical Productivity Railsware Way by Yaroslav Lazor). It’s strange but the same list distributed into three or four lists (each under “M”, “S”, “C” or “W”) looks not so scary and even appears to be pretty motivating.

Share
* Railsware is a premium software development consulting company, focused on delivering great web and mobile applications. Learn more about us.
  • http://www.facebook.com/honghavo Ha Vo

    Btw, did you know that ‘The original MoSCoW Rules were the CIA guidelines for operatives working in Eastern Europe in the 1960s’?

    • Dmitry Pliska

      No. Its interesting. And, actually, it makes sense :)

Want to get more of Railsware blog?

RSS FEED

We're always ready to help!

CONTACT US