How I Stopped Worrying and Learned to Love Prioritization

[article]

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) 

 

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.

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.

AgileConnection 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

Oct 12
Oct 15
Nov 09
Nov 09