How to Use the MoSCoW Prioritization Method in Agile Project Management

How to Use the MoSCoW Prioritization Method in Agile Project Management

If a genie granted you one wish, what would you ask for? To retire at 40? A second home in Hawaii?

What if he granted you three wishes?

Since this is just fantasy, let’s go ahead and dream really big…..imagine you had ten!

Chances are, with ten wishes, you’d be tied up in knots, flummoxed, trying to find clarity amongst your “must haves.”

Identifying priorities in a really complicated project feels about the same.

When looking through the product backlog feels like rifling through the kitchen catch-all drawer, how do you distinguish the “must-dos” from the “must-do-right-nows”?

Even when you know the deadline, and a lot of other constraints, it’s hard to know where to actually begin.

When you’re tangled up in a must-trap, it feels like the only way out is for a genie to appear, sort through everything, and tell you: “Here. This is what you need to work on Right. Now.”

The truth is, you can get untangled yourself. The MoSCoW Method of prioritization lets you know what you need to work on now, and what tasks can be put off until tomorrow. And it’s really simple to boot!

That’s not too hard to believe, is it?!

The Moscow Method Defined

When you hear about the MoSCoW Method for the first time, it probably conjures up images of St. Basil’s Cathedral, the Kremlin, and Red Square.

The truth is, however, that the MoSCoW Method has nothing to do with Russia at all!

It was developed in 1994 by Dai Clegg, a software developer working at Oracle. MoSCoW really represents the acronym, MSCW. The vowel sounds are added to make it easier to pronounce (and it makes it sound pretty cool, too!).

Each letter in MoSCoW represents a separate layer for task prioritization: Must, Should, Could, and Won’t. By organizing tasks into these categories, a team finds clarity around what it needs to work on right now, and in the near future.

Here’s a breakdown of the kind of tasks that go in each category.

• Must
  A must is any task that’s essential to a project. It’s part and parcel to the overall objective, and not doing it would create a bottleneck.
  Musts include any feature requirement from a client. These are the things to put into a sprint backlog for the upcoming iteration.
• Should
  Shoulds are things that need to be completed, but aren’t on the front burner. These can stay in the product backlog for a later i
• Could
  Coulds are ancillary tasks; things that would be nice to do, given that resources are available. They don’t need to happen in this iteration or the next. Coulds go into the product backlog.
• Won’t
  Won’ts are any tasks that just can’t happen within the constraints of the project, and aren’t required to meet basic requirements. Won’ts are removed from the product backlog.
  Won’ts are also sometimes referred to as “would haves” or “wish to haves,” because they can be things that would improve a deliverable, but are just outside of the scope or budget.

An Example Using MoSCoW

It’s all pretty simple, huh? The MoSCoW Method is helpful in the initial stages of project planning, as it’s about clarifying and crystallizing what the project really is all about. It helps to manage expectations for all stakeholders.

Let’s look at an example of using the MoSCoW Method at the beginning of a project. Let’s say you’re planning the remodel of a kitchen.

The musts include the primary reasons for the remodel, such as moving the dishwasher next to the sink, improving the lighting, and increasing the size of the sink.

The shoulds are things that need to be taken into account, secondarily. This may include things like putting outlets in the right places.

Coulds are special things to add, such as custom cabinets or a tile backsplash, so long as they work into the time frame and budget.

Won’ts are things that just won’t happen, given the overall constraints. These might include things like adding a Viking stove, because it’s too expensive, or a marble countertop, as it wouldn’t handle moisture.

Strengths of the MoSCoW Method

MoSCoW makes it easy to chart a course at the beginning of a project. Let’s look at a few reasons the MoSCoW Method assists in successful project implementation.

A Simple Conceit

The MoSCoW Method, as you’ve just witnessed, is pretty easy to explain and understand.

Unlike scrum or many of the principles in agile, anyone can figure out MoSCoW in just a few minutes.

This simplicity allows the business, customer, developers, and any other stakeholders in a project all to participate and make meaningful contributions toward determining the musts, shoulds, coulds, and won’ts of a project.

Broad Buy-in

When all stakeholders are able to participate in discussing projects, and all of the tasks are ordered and prioritized, it makes the entire project transparent.

It’s much easier to get stakeholders on board when they see all the cards laid out, and can offer their own perspective.

And as any project manager will tell you, having every stakeholder understand the goal and constraints of a project from the beginning is critical to its success.

Crystal Clear Objectives

When a project has too many North Stars, or there’s some sort of a “let’s do this” mentality without much of a plan, the team flails and it creates a lot of dissension later on.

The MoSCoW Method creates clarity around what a project sets out to do (and what it won’t do) from the very beginning. This is perhaps its greatest strength.

When all the stakeholders understand a project’s final objective, it really helps to manage expectations down the road, and decreases the likelihood of having to change course late into the project.

As you can see, Clegg was really onto something when he developed the MoSCoW Method. It didn’t catch on just because of the great name.

Nor is it sheer perfection, however.

Weaknesses of the MoSCoW Method

Although an effective project management tool, The MoSCoW Prioritization Method isn’t fool-proof. Let’s look at a few of its flaws.

It’s Too Simple

But wait! Isn’t simplicity one of MoSCoW’s strengths?

Well, as with so many things in life, one of the strengths of the MoSCoW Method is also one of its biggest weaknesses.

Although MoSCoW is a great way to plot out a project at the beginning, this isn’t a stopping point.

Simply putting tasks into four categories doesn’t provide enough clarity to move forward. When you have six to eight things in the “must” category, it’s necessary to dig and refine a bit further to determine where to actually begin.

Additionally, if these “must” tasks are really huge, they need to be broken down and simplified into stories that can be completed in a sprint.

For larger complex projects, it’s also helpful to organize stories into epics, themes, and features in order to find clarity around priorities and determine what to put into a sprint.

Bogus “Musts”

A project with a lot of stakeholders generally means a variety of interests and motivations.

An agile team plans each iteration with the end user in mind. However, managers higher up in the chain of command may well work toward different incentives, and create “musts” that don’t really benefit the project, but that are motivated by politics or pay.

With a variety of conflicting “musts”, the agile approach of working toward the end user gets sidelined, and a team may end up having to complete a “must” that doesn’t really improve the deliverable at all.

Fixation on Musts

The MoSCoW Method is a bit like waterfall in that it creates a set of priorities at the onset.

The team can easily become cemented into these objectives, even when the client’s needs change, or the market changes in the duration of the project.

As it wouldn’t allow for fluidity and change, depending entirely on MoSCoW Method may lead to a dissatisfied client.

As you can see, although MoSCoW has a lot of strengths, it’s not something that a team should lean on entirely. It’s important to be aware of this method’s shortcomings as well, and to use it judiciously.

MoSCoW With Agile Teams

Using the MoSCoW Method really helps agile teams prioritize the product backlog for the upcoming iterations. Plus, it keeps the team from wasting time on pointless tasks.

However, when using the MoSCoW Method, it’s necessary to keep the principles of the Agile Manifesto front-of-mind as well.

Here are a few pointers.

Gather Input from All Stakeholders

Although a scrum team in isolation can easily come up with its own musts, shoulds, coulds, and won’ts, this list would look pretty different than someone else who has a stake in the project.

The Agile Manifesto says to value “individuals and interaction over processes and tools” and that “our highest priority is to satisfy the customer.”

In creating the product backlog, a team needs to gather input from all stakeholders.

An integrated list of priorities that considers all perspectives makes a project better poised to chart a path that satisfies the end user.

Use Mental Agility

Although it’s helpful to us MoSCoW to identify a project’s “musts” and “shoulds,” an Agile team also needs to be cognizant of the principle from the Agile Manifesto that states: “welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Mental agility refers to a team’s ability to adapt and course correct.

When a team identifies that the client’s needs have changed over the course of a project, it uses this mental agility to scrap some of its plans, and readjust.

Clarifying “musts” and “shoulds” provides much-needed guidance. But it’s just as necessary to allow for course correction.

Stay in the Weeds

The MoSCoW Method can look a bit like a gantt chart: it plots out an entire project at the very beginning.

This big-picture approach goes against the agile process of creating increment during each sprint, reflecting then pivoting.

In order to be agile, teams need to keep the big-picture approach, but to focus on each sprint as well. The increment, feedback and reflection may alter the course.

In sum, the MoSCoW Method is a helpful tool for an agile team. But it shouldn’t be used like a compass. Some of the rigidity implicit in the MoSCoW Method really brushes against the agile methodology and could chart the team off course.