HOW TO PRIORITIZE REQUIREMENTS

When starting a new project, very often happens that clients come to me with a huge list of requirements. They want them all. And they want them now. All of them are very important of course. And they all should be developed.

Sure.

The reality is that often we don’t have all the resources we need to develop all requirements at once. But what’s more important is that it can be very risky to develop all of them without questioning their importance and priority.

It’s extremely important to sit down with a client and go through the list of requirements together. We should start by developing the most important functionality, therefore we need to prioritize.

Yes or yes.

But this takes us to the next question:

How do you know what functionality is the most important?

There are several techniques that can help you prioritize requirements. There isn’t a magic formula and it very depends on the project. But a technique that I find very useful and that can be applied to agile and waterfall projects is the MoSCoW technique.

MoSCoW has nothing to do with the Russians, instead it stands for:
M – MUST
S – SHOULD
C – COULD
W – WON’T

Let’s have a closer look at each of them.

 

M – MUST

These are fundamental requirements. Without them the product would be useless, it wouldn’t work. The product cannot be release without them and you should expect to deliver all of these.

Imagine we are developing the Whatsapp application. A must have would be the ability to chat with friends by sending messages to each other. And also to have separate chat rooms for each of your friends.

 

S – SHOULD

These are still important requirements but they didn’t make it to the MUST list because of lack of time, resources or budget. You can still expect to deliver a few of these.

In our example, being able to change your status, turn on/off notifications and add new contacts can fall into the SHOULD list.

 

C – COULD

These requirements are nice to have but the product won’t be affected if they are not included. The team can develop them if they are relatively easy and only if they don’t put at risk any MUSTs or Shoulds

In our example these could be the ability to send video or image files to your friends.

 

W – WON’T

You will place here requirements that can wait. It doesn’t mean that they are not valuable, we still want them, but will not be developed this time. We should not forget about these as they can become a MUST in the next phase of development. Having a WON’T list is very useful for your designers as they can see what’s the trend and therefore design with these requirements in mind to accommodate the WON’Ts in a future release.

In our example, the call and video call are functions that could fall into the WON’T category because they will be developed in a future iteration.  The app will still function without them. People can still send messages to each other. Yes, now that we have those functions available in our Whatsapp we are really enjoying them but if you think about it they were not available when the app first launched.

 

RECOMMENDATIONS

Whenever you’re prioritizing, you have to be rigorous on what really is a priority. Not everything can be included as a MUST and trade-offs would need to be made.

My advice is to work on prioritization as early as possible, whether you do it only yourself for your own particular project or whether you work on it with your project manager.

If you’re struggling to come up with the MUSTs and the SHOULDs one thing you can do is to work backwards: Assign everything to the WON’T list and then ask yourself or your stakeholder to justify why a particular requirement should be moved higher on the list.

If during the project, as you work on your sprint, a new requirement arises, don’t be afraid to adjust or change your priorities. If you’re working in an agile environment you can accommodate changes as you go. You won’t be changing the work planned for the particular sprint you’re working on but for the next one, you can change your product backlog and introduce that new requirement. That’s the beauty of agile. You should be flexible and always consider the feedback you’re getting from customers instead of sticking to a plan that may not make much sense after all.

Another thing that can happen is having an item in the MUST have list only because it has been described at a very high level. If you have doubts, break down the requirement into smaller ones until you get a better picture of what is really a priority and what is not.

 

QUALITY VS QUANTITY

From my experience I can say that is better when a project is delivered on time with a few features, instead of delaying the project just because you’ve decided to include too many. You should aim for release early and often, instead of focusing on covering every single feature since the beginning.

Sometimes happens that teams are put under pressure to deliver more features than they physically can. And this often results in giving up quality. In this case, you may be releasing on time, but the software would have too many faults and would be very brittle which could damage your brand reputation.

 

 

In conclusion, you cannot have everything and have it now. You need to prioritize and understand that you may not be able to deliver all features you have thought of in the first place.

Work on your MoSCoW lists and aim for releasing working software early and often. This way you’ll notice how things move forward while avoiding unnecessary risks.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*