Professional Documents
Culture Documents
How I Stopped Worrying and Learned To Love Prioritization
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.
But stop right there! There's a trick or two you should know about.
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.
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.
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.
If we can agree on that priority of goals, we can then agree on a feature priority that looks something like
this:
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.
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:
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.