 |
Home > Detail: How I Stopped Worrying and Learned to Love Prioritization
| A StickyMinds.com Original |
|  | |
How I Stopped Worrying and Learned to Love Prioritization
By Jeff Patton
   
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:
- 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.
- 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:
- Look up items
- View item information
- Browse new releases
- 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 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:
- Look up items (Must)
- View item information (Must)
- Special order out of stock items (Should)
- 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:
- Look up item by name (Must)
- Look up item with a misspelled or partial name (Should)
- Look up item by artist (Should)
- Look up item by song title (Could)
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.
Back to Top
StickyMinds.com Weekly Column From 9/1/2008
|
