About Scrum

Scrum Priorities and Buckets

Friday, January 30 2009 - scrum, agile, priority, buckets

More than once, I've heard Scrum Masters express the importance of prioritizing a product backlog in the exact order of priority -- so if you have 100 items in the backlog, the product owner ought to prioritize them from 1 to 100. The argument is that this level of prioritization provides the following benefits:

• Makes sprint planning that much simpler...the team can take the top priority items for the next sprint
• If any items are left off in order to complete a sprint on time, the team will know the items that were left out were of lower importance than the items they included.

While those benefits are great, the drawbacks of this level of prioritization are rarely discussed by its proponents (and there are some serious drawbacks). When dealing with large sets of items, generally more than 20, it's highly unlikely that the exact order of all the items is important to the product owner. However, to satisfy this arbitrary constraint, the product owner is forced to do the following:

• Spend WAY too much time on item prioritization
• Arbitrarily prioritize items of equal importance:  for example, the product owner might consider five items of equal importance and not care which item is done first or last, however, to satisfy the prioritization constraint, the owner will spend time assigning the five items priorities of 16, 17, 18, 19 and 20.
  • Based on the false assumption that the product backlog is prioritized in an exact order of importance, when the team is forced to cut a feature, they would start with item 20, then 19, then 18 and so on...

Now consider the following time estimations for items 16 through 20:

• Item 16: 5 Days
• Item 17: 1 Day
• Item 18: 1 Day
• Item 19: 1 Day
• Item 20: 1 Day

And remember that in this example, the product owner believes that Items 16 through 20 are equally important. However, when the team needs to shave off 4 days worth of work in order to meet their deadlines, the team goes through and axes Items 17 through 20. Bad choice! Had the product owner known the team was about to cut off 4 out of 5 equally important items, s/he might have opted to have Item #16 cut, rather than the other four.

That way, four of the five items would have been completed instead of axed.

A Better Way: Using Priority Buckets

There is a much better way to prioritize. The traditional Low-Medium-High is a better way, but those three groups may not provide sufficient priority levels. But, that doesn't mean the answer is one priority for each item.  Software doesn't have to be developed by jumping to extremes or using rigid development methodologies. In fact, Scrum was intended to be just the opposite: agile and flexible. It's ironic when some in the Scrum community try so hard to codify and systematize every aspect of scrum.

Priority Buckets allow a team (or a product owner) to decide up front how many priority levels they need for the project. In most cases 10 priority levels is more than enough, but that's not a hard and fast rule. Feel free to use 100 priority buckets if that makes more sense in your case. However, the flexibility of the priority buckets is that the product owner could group items into the same bucket.

So looking at the above example again, lets assume the product owner decided to have 10 priority buckets. Then he or she could have prioritized items 16 through 20 into one of those priority bucket, such as priority bucket #7. The team could then decide on the order iof all the items inside the same priority bucket. And, if/when the team needed to axe four days of work, the team would have easily recognized that eliminating item #16 is the smart choice allowing them to still finish the vast majority of items on their product backlog.