How I Stopped Worrying and Learned to Love Prioritization

By Jeff Patton

One of the more challenging things about moving to agile software development is breaking up your
software requirements into small, buildable chunks. Often these chunks are expressed as simple, single-
line "user stories" or backlog items that we intend to develop starting with highest value or highest
priority. If you've spent any time in software development, I suspect you've seen the prioritized list where
most items in the list range from high priority to "very, very" high priority. These lists used to stress me a
lot. Although they're still a bit annoying, today I better understand the reasons they are that way and have
some easy techniques for working with them that leave me significantly less stressed.

MoSCoW Prioritization Separates Chunks into Four Piles.

The term MoSCoW is taken from the first letters of Must, Should, Could, and Won't plus a couple of
extra Os. They represent four piles: Must Have, Should Have, Could Have, and Would Be Nice But
Probably Won't. This simple prioritization approach is reasonably straightforward to use. If we step
through our backlog of items to build, we simply tag each chunk with an M, S, C, or W.

But stop right there! There's a trick or two you should know about.

Make Your Business Goals Explicit

An often overlooked fact about prioritization is that priority is determined in the context of some business
goals or objectives. If the bit of scope helps us reach the goal, it's high priority. If it doesn't, it's low.
Making those goals or objectives explicit is the first, most important trick to prioritization.

Let's take a simple example I often use in teaching. In this example, I describe a fictitious retailer of
books and music--one that likely looks a lot like a retailer in your city. This retailer has a huge selection
of inventory and, with it, a problem. Its customers can't always find what they're looking for and often
leave the store unhappy without spending money. In my example the retailer wants to build an in-store
kiosk that customers can use to look for a book or music title and determine if it's in stock and where it's
located in the store. If the title isn't in stock, the customer could then special order it.

If we were to identify the goals, we could say:

1. To increase revenue and customer satisfaction, help people who know what they want to find it by
allowing them to look up specific items and in-store location on a kiosk.
2. To increase revenue, allow customers to special order specific items not in stock.

Identifying those goals is the first step.

Now, if we look closely at a backlog of given functionality, we might have a few items like these:

1. Look up items
2. View item information
3. Browse new releases
4. Special order out of stock items

Before stating the goals, a stakeholder from merchandising might have strongly argued that "Browse new
releases" was definitely a Must Have. Now that we've agreed that looking for specific items is most

1
critical, we can more easily agree that "Browse new releases" would be a Could Have. But, most likely,
stakeholders would like to see the remainder of items in the Must Have bucket.

Let's pull out our second trick.

Prioritize Your Goals First

Looking at those two goals and discussing our business problem, we might agree that our biggest problem
is the people walking out empty handed after looking around the store for a while. That's especially
frustrating if we actually had what they wanted in stock. We want most of our customers happy with a
product in their hands, and the sooner the better. Given that, we might say it's more important to hit goal
number one--looking up items and in-store location.

If we can agree on that priority of goals, we can then agree on a feature priority that looks something like
this:

1. Look up items (Must)

2. View item information (Must)
3. Special order out of stock items (Should)
4. Browse new releases (Could)

That's a bit better. But let's say urgency is high here, and as a business person you'd like this problem in
your stores addressed as soon as possible. After some discussion and elaboration, those Must Have
product features have estimates that seem way too high.

Don't get stressed yet, we've got one more trick to go.

Decompose Work, Then Prioritize Again

To develop the software, it's helpful to break the work down into small, developable pieces. Finishing
small pieces helps us better track progress towards done. However, when you decompose a "Must Have"
scope item, it's safe to assume that all possible scope items inside it aren't Must Have.

Let's look closely at the Must Have piece of scope, "Look up item." There are a lot of ways to look up an
item on an in-store kiosk. If I begin to list a few and, while thinking about the goals for the product, tag
them using the MoSCoW notation, I can see that simply looking up an item by its name is a Must Have.
But, strengthening the lookup by adding some support for partial or misspelled names and other forms of
lookup are all Should Have or Could Have. A decomposition of scope item under "Look up item" might
go a bit like this:

1. Look up item by name (Must)

2. Look up item with a misspelled or partial name (Should)
3. Look up item by artist (Should)
4. Look up item by song title (Could)

2
In agile development, this decomposition is
often done later--or at the "last responsible
moment," as the agile mantra states. This
means we defer this decision until later
when we have the best understanding we
can from the software we've built thus far. I
also find that as the release date draws near,
items that were Must Have or Should Have
a month or two ago suddenly start looking
like Could Haves when meeting a delivery
date is in question.

Deferring decomposition and

reprioritization until that last responsible
moment isn't for everyone. I suspect we'd all love to know exactly what we'll get and exactly how long it
will take to get it. But, for me, the challenge has always been in knowing exactly what I want to get and
then balancing that against the desire to get something valuable out as soon as possible. It's made me feel
more confident that I can deliver something valuable on time by being clear about goals and prioritizing
scope within the context of those goals, along with knowing that I can keep playing this prioritization
game as I decompose. And that's how I learned to stop worrying and love prioritization.

About the Author

Jeff Patton leads teams of Agile developers to build the best software possible. He proudly works at
ThoughtWorks. Jeff's series of columns on software design and pre-design tips appears regularly on
StickyMinds.com. Jeff's blog, presentations, and other articles can be found at
www.agileproductdesign.com. Among Jeff's accomplishments, he can add winning the 2007 Gordon Pask
Award, which he received at the Agile2007 Conference in August.