How I Stopped Worrying and Learned to Love Prioritization

[article]
Summary:

Managing an agile project based on uncensored "Very High," "High," and "Low Priority" user stories or backlog items used to induce stress on Jeff Patton. So he learned to implement a combination of prioritization techniques to get these lists--and the job--under control. In this week's column, find out how Jeff utilizes MoSCoW and business goals to make sense of prioritization.

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 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

User Comments

1 comment
Peter Trudelle's picture
Peter Trudelle

I'd really like "Won't" to mean "Don't", indicating things that are not desired, or not worth the effort/risk/complexity.

September 20, 2012 - 5:29pm

About the author

Jeff Patton's picture Jeff Patton

Jeff Patton leads Agile Product Design, a small consultancy that focuses on creating healthy processes that result in products that customers love. Articles, essays, and blog can be found at www.AgileProductDesign.com. Information about public classes, including Certified Scrum Training, can be found at www.AgileProductDesign.com/training.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Apr 29
Apr 29
May 04
Jun 01